This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

O_ACCMODE is wrong


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: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]