X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 22 Mar 2011 19:01:09 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: O_ACCMODE is wrong Message-ID: <20110322180109.GH31220@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4D88DF18 DOT 8050401 AT redhat DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D88DF18.8050401@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 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