From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6208 Path: news.gmane.org!not-for-mail From: "Anthony G. Basile" Newsgroups: gmane.linux.lib.musl.general Subject: Re: fdopen/fflush problem Date: Sat, 27 Sep 2014 12:56:14 -0400 Message-ID: <5426EC2E.4070301@opensource.dyc.edu> References: <54250245.2070108@i-soft.com.cn> <20140926061810.GQ23797@brightrain.aerifal.cx> <20140926063939.GF21835@port70.net> <20140926070548.GR23797@brightrain.aerifal.cx> <20140926072343.GS20593@example.net> <5426BBB0.1090309@opensource.dyc.edu> <20140927133813.GV23797@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1411836987 29629 80.91.229.3 (27 Sep 2014 16:56:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Sep 2014 16:56:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6221-gllmg-musl=m.gmane.org@lists.openwall.com Sat Sep 27 18:56:21 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XXvIB-0005kB-SQ for gllmg-musl@plane.gmane.org; Sat, 27 Sep 2014 18:56:19 +0200 Original-Received: (qmail 18068 invoked by uid 550); 27 Sep 2014 16:56:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18039 invoked from network); 27 Sep 2014 16:56:15 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 In-Reply-To: <20140927133813.GV23797@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6208 Archived-At: On 09/27/14 09:38, Rich Felker wrote: > On Sat, Sep 27, 2014 at 09:29:20AM -0400, Anthony G. Basile wrote: >> On 09/26/14 03:23, u-wsnj@aetey.se wrote: >>> On Fri, Sep 26, 2014 at 03:05:48AM -0400, Rich Felker wrote: >>>> unspecified if the flag argument contains more than the following >>>> flags:" >>>> >>>> The list that follows includes just O_APPEND, O_CLOEXEC, and O_*SYNC, >>>> so including O_WRONLY has unspecified behavior. However, since this is >>>> just unspecified, not undefined, it seems bad for something "horribly >>>> wrong" to happen, like a file with no access like we're getting now. >>>> Indeed, POSIX will define an optional error: >>>> >>>> "The mkostemp( ) function may fail if: >>>> >>>> [EINVAL] The value of the flag argument is invalid." >>>> >>>> So I think we should either make this error be detected, or silently >>>> mask off the bad access mode. My leaning would be towards reporting it >>>> as an error. Opinions? >>> >>> +1 (reporting an error) >>> >>> Rune >>> >> >> Both uclibc [1] and glibc are okay with the flag combination >> O_WRONLY|O_CLOEXEC. With unspecified behaviour you really can't say >> which way to go here for portability. The correct thing to do would >> be to get this behaviour specified (in SUSv4 or something??) since >> mkostemp is currently a GNU-ism. > > Except that it's not; it's accepted for POSIX and you can read the > text for it here: > > http://austingroupbugs.net/view.php?id=411 Thanks. I didn't know that. > > It seems the unspecified behavior is intentional. But I don't see > anything you could meaningfully do with the access mode since it's not > mandatory; an explicit mode of O_RDONLY would be indistinguishable > from a request for the default (O_RDWR), which is not a big problem > since O_RDONLY doesn't make sense for a new file you're creating, but > this only works because O_RDONLY happens to be the one with value 0. > If O_WRONLY had the value zero, you couldn't honor it. So really, the > only viable implementation choices seem to be silently ignoring the > mode, or throwing an error if any mode bits are specified. And since > we can't detect all modes (e.g. O_RDONLY can't be detected since it's > 0) I think it somewhat makes sense, from a consistency standpoint, to > just ignore the access mode bits... Yeah, makes sense. > >> [1] In uclibc libc/stdlib/mkostemp.c calls __gen_tempname in >> libc/misc/internals/tempname.c with kind = __GT_FILE and opens the >> file with >> >> fd = open (tmpl, O_RDWR | O_CREAT | O_EXCL, mode); >> >> which is different from how musl does it in __mkostemps in >> src/temp/mkostemps.c >> >> fd = open(template, flags | O_RDWR | O_CREAT | O_EXCL, 0600); >> >> Looks like uclibc completely ignores O_APPEND, O_CLOEXEC, and O_*SYNC. > > Wow. So they just made a fake version of this function which ignores > the whole purpose it was created for -- atomic close-on-exec? Care to > report this? > > Rich > Yes, I am definitely going to report this. Defeating the atomic O_CLOEXEC is painful. This is the second time atomicity was overlooked in uclibc (that I know of), the other being pread/pwrite implemented as open/lseek/{read,write}. I'm not sure if this is legacy cruft going back to time when linux kernels didn't provide the support or what. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197