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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
