| From: | Ken Raeburn <raeburn@MIT.EDU> |
| To: | krb5-bugs@MIT.EDU |
| Subject: | better handling of close-on-exec race |
| Date: | Tue, 5 Aug 2008 03:52:53 -0400 |
Newer Linux kernels (and I guess glibc versions) are getting support
for having new file descriptors have the close-on-exec flag set from
the start, eliminating the race condition. We probably want a similar
fix -- wrappers for open, fopen, accept, and so on, that use these
hooks if present, and otherwise perform the traditional operation and
then set close-on-exec as quickly as possible.
Begin forwarded message:
for having new file descriptors have the close-on-exec flag set from
the start, eliminating the race condition. We probably want a similar
fix -- wrappers for open, fopen, accept, and so on, that use these
hooks if present, and otherwise perform the traditional operation and
then set close-on-exec as quickly as possible.
Begin forwarded message:
Show quoted text
> From: Andrew Bartlett <abartlet@samba.org>
> Date: August 4, 2008 19:58:46 EDT
> To: Love Hörnquist à strand <lha@kth.se>
> Cc: heimdal-discuss <heimdal-discuss@sics.se>
> Subject: Re: [Heimdal-source-changes] heimdal r23441 - trunk/heimdal/
> lib/roken
> Reply-To: heimdal-discuss@sics.se, Andrew Bartlett
> <abartlet@samba.org>
> X-Spam-Score: 0.13
>
> On Mon, 2008-07-28 at 08:26 +0100, Love Hörnquist à strand wrote:
> Just to keep you busy, this should summarise all the calls and the way
> they have been adjusted to avoid this race:
>
> http://udrepper.livejournal.com/20407.html
>
> Andrew Bartlett
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Red Hat Inc.
> Date: August 4, 2008 19:58:46 EDT
> To: Love Hörnquist à strand <lha@kth.se>
> Cc: heimdal-discuss <heimdal-discuss@sics.se>
> Subject: Re: [Heimdal-source-changes] heimdal r23441 - trunk/heimdal/
> lib/roken
> Reply-To: heimdal-discuss@sics.se, Andrew Bartlett
> <abartlet@samba.org>
> X-Spam-Score: 0.13
>
> On Mon, 2008-07-28 at 08:26 +0100, Love Hörnquist à strand wrote:
>> 28 jul 2008 kl. 01.15 skrev Andrew Bartlett:
>>
>> We need to to do it for socket/fopen/opendir too, and I rather not
>> sprinkle that 5 lines all over the place.
>>
>> That said, we should pass in O_CLOEXEC to open(2) calls too (just
>> like
>> we do with O_BINARY).
>>
>> Thanks for point O_CLOEXEC out, I had totally missed that.
>>>
>>> On Sun, 2008-07-27 at 14:05 +0200, lha@it.su.se wrote:
>>> Is this really the right way to do this?
>>>
>>> Given that recent Linux has a completely race-free way of handling
>>> this,
>>> shouldn't this be added to a roken version of open(), emulated on
>>> other
>>> systems?
>>>>>> Author: lha
>>>> Name: Love Hrnquist strand
>>>> Date: 2008-07-27 14:05:11 +0200 (Sun, 27 Jul 2008)
>>>> Repository: heimdal
>>>> Repository Path:/afs/su.se/services/svn/heimdal
>>>> New Revision: 23441
>>>>
>>>> Added:
>>>> trunk/heimdal/lib/roken/cloexec.c
>>>> Log:
>>>> Wrapper function for close on exec().
>>>>>>> Name: Love Hrnquist strand
>>>> Date: 2008-07-27 14:05:11 +0200 (Sun, 27 Jul 2008)
>>>> Repository: heimdal
>>>> Repository Path:/afs/su.se/services/svn/heimdal
>>>> New Revision: 23441
>>>>
>>>> Added:
>>>> trunk/heimdal/lib/roken/cloexec.c
>>>> Log:
>>>> Wrapper function for close on exec().
>>> Is this really the right way to do this?
>>>
>>> Given that recent Linux has a completely race-free way of handling
>>> this,
>>> shouldn't this be added to a roken version of open(), emulated on
>>> other
>>> systems?
>> We need to to do it for socket/fopen/opendir too, and I rather not
>> sprinkle that 5 lines all over the place.
>>
>> That said, we should pass in O_CLOEXEC to open(2) calls too (just
>> like
>> we do with O_BINARY).
>>
>> Thanks for point O_CLOEXEC out, I had totally missed that.
> Just to keep you busy, this should summarise all the calls and the way
> they have been adjusted to avoid this race:
>
> http://udrepper.livejournal.com/20407.html
>
> Andrew Bartlett
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Red Hat Inc.