From: Eric Blake <ebb9@byu.net>
To: Florian Weimer <fweimer@bfk.de>
Cc: Davide Libenzi <davidel@xmailserver.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
bug-coreutils@gnu.org, bug-gnulib@gnu.org,
Ulrich Drepper <drepper@redhat.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] open: introduce O_NOSTD
Date: Fri, 28 Aug 2009 07:04:40 -0600 [thread overview]
Message-ID: <4A97D5E8.8010906@byu.net> (raw)
In-Reply-To: <82ocq0p0ba.fsf@mid.bfk.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Florian Weimer on 8/28/2009 6:52 AM:
> * Eric Blake:
>
>> Your version fails to clear the cloexec bit of the final fd if the
>> original caller didn't request O_CLOEXEC.
>
> Okay, but you can fix that in a race-free manner (but I thought that
> this was implied by open_safer).
The current semantics of gnulib's open_safer is that the result is
guaranteed to be 3 or larger. It would require an audit of all gnulib
clients of the open_safer method to see whether it also makes sense to
change the semantics of open_safer to also guarantee that fds start life
with the cloexec bit set. But maybe that is a change worth making in
gnulib, with applications intending to give an fd to a child process being
required to explicitly clear the cloexec bit.
>> Also, your suggestion has a definite race in that you are calling
>> open() multiple times rather than cloning an existing fd after the
>> first open(), such that another process could alter which file is
>> visited between your first and last open().
>
> Sure, but this is an unobservable differen.ce
It is absolutely observable - if the user passed O_CREAT|O_EXCL as part of
their flags, then the second open() will inappropriately fail.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqX1egACgkQ84KuGfSFAYDKWACeMM4spqCsmgVVwME9+C/1tdpU
g7wAnR9FetGPGr7acXLfLIVvzYZ7tpz3
=VjUY
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-08-28 13:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-24 12:22 [RFC] new open flag O_NOSTD Eric Blake
2009-08-25 12:16 ` [PATCH] open: introduce O_NOSTD Eric Blake
2009-08-25 21:53 ` Davide Libenzi
2009-08-27 13:54 ` Eric Blake
2009-08-27 14:22 ` Ulrich Drepper
2009-08-28 12:28 ` Eric Blake
2009-08-27 14:35 ` Florian Weimer
2009-08-28 12:45 ` Eric Blake
2009-08-28 12:52 ` Florian Weimer
2009-08-28 12:58 ` Eric Blake
2009-08-28 13:04 ` Eric Blake [this message]
2009-08-27 22:55 ` Davide Libenzi
2009-08-27 23:11 ` Ulrich Drepper
2009-08-30 11:12 ` [RFC] new open flag O_NOSTD James Youngman
2009-08-30 11:18 ` Jim Meyering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A97D5E8.8010906@byu.net \
--to=ebb9@byu.net \
--cc=bug-coreutils@gnu.org \
--cc=bug-gnulib@gnu.org \
--cc=davidel@xmailserver.org \
--cc=drepper@redhat.com \
--cc=fweimer@bfk.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.