O_ACCMODE is wrong

O_ACCMODE is wrong

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

First, some background: POSIX 2008 introduced O_SEARCH and O_EXEC, and
states that they may (but not must) share the same bit, since the former
is for directories and the latter for non-directories (cygwin shares
these as 0x400000).  POSIX states that implementations need not reject
O_EXEC|O_RDONLY (to cater to systems like cygwin where O_RDONLY is 0),
but that they may on systems where it is detectable (such as on Hurd
where O_RDONLY is 1).  It also requires that an application must provide
exactly one of the five modes O_RDONLY, O_WRONLY, O_RDWR, O_SEARCH, or
O_EXEC), and therefore an implementation should reject a bit-wise or
that tries to mix those modes).

However, in introducing the new values, POSIX also required that
O_ACCMODE be updated to cover those new modes.

Now for the bugs: cygwin's <fcntl.h> defines O_ACCMODE as 3 instead of
0x400003, and as a result, a regular file opened for O_EXEC (or a
directory for O_SEARCH) but probed via fcntl(F_GETFL)&O_ACCMODE will
mistakenly show up as O_RDONLY instead of the proper mode.  Meanwhile,
open(O_EXEC|O_WRONLY) isn't rejected as an invalid mode.  However, just
changing O_ACCMODE to the correct value may expose other latent bugs in
the rest of cygwin1.dll, since it looks like there are existing places
where cygwin is making assumptions that rely on O_ACCMODE being exactly
3, so it would require a careful audit to fix it all.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: O_ACCMODE is wrong

[Corinna Vinschen]

On Mar 22 11:40, Eric Blake wrote:
> First, some background: POSIX 2008 introduced O_SEARCH and O_EXEC, and
> states that they may (but not must) share the same bit, since the former
> is for directories and the latter for non-directories (cygwin shares
> these as 0x400000).  POSIX states that implementations need not reject
> O_EXEC|O_RDONLY (to cater to systems like cygwin where O_RDONLY is 0),
> but that they may on systems where it is detectable (such as on Hurd
> where O_RDONLY is 1).  It also requires that an application must provide
> exactly one of the five modes O_RDONLY, O_WRONLY, O_RDWR, O_SEARCH, or
> O_EXEC), and therefore an implementation should reject a bit-wise or
> that tries to mix those modes).
> 
> However, in introducing the new values, POSIX also required that
> O_ACCMODE be updated to cover those new modes.
> 
> Now for the bugs: cygwin's <fcntl.h> defines O_ACCMODE as 3 instead of
> 0x400003, and as a result, a regular file opened for O_EXEC (or a
> directory for O_SEARCH) but probed via fcntl(F_GETFL)&O_ACCMODE will
> mistakenly show up as O_RDONLY instead of the proper mode.  Meanwhile,
> open(O_EXEC|O_WRONLY) isn't rejected as an invalid mode.  However, just
> changing O_ACCMODE to the correct value may expose other latent bugs in
> the rest of cygwin1.dll, since it looks like there are existing places
> where cygwin is making assumptions that rely on O_ACCMODE being exactly
> 3, so it would require a careful audit to fix it all.

Given that O_EXEC and O_SEARCH are not used anywhere in Cygwin it's not
exactly a pressing issue.  If you want to add the correct handling, feel
free to send a patch.


Corinna


P.S.: In theory this is better suited for the cygwin-developers list...


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple