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
