Skip Menu |

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
Download (untitled) / with headers
text/plain 2.1KiB
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:

Show quoted text
> From: Andrew Bartlett <>
> Date: August 4, 2008 19:58:46 EDT
> To: Love Hörnquist Åstrand <>
> Cc: heimdal-discuss <>
> Subject: Re: [Heimdal-source-changes] heimdal r23441 - trunk/heimdal/
> lib/roken
> Reply-To:, Andrew Bartlett
> <>
> 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:
>>> On Sun, 2008-07-27 at 14:05 +0200, wrote:
>>>> Author: lha
>>>> Name: Love Hrnquist strand
>>>> Date: 2008-07-27 14:05:11 +0200 (Sun, 27 Jul 2008)
>>>> Repository: heimdal
>>>> Repository Path:/afs/
>>>> 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:
> Andrew Bartlett
> --
> Andrew Bartlett
> Authentication Developer, Samba Team
> Samba Developer, Red Hat Inc.
For most programs, the race condition isn't much of an issue, because we'd have to have a
multithreaded program (or one doing funny things in signal handlers) that can spawn a user-
controlled or at least user-accessible process at a point where extra file descriptors are open.
So it needn't be high priority.

The developer systems we're using now aren't new enough to have support for the syscall
changes, so we can't actually test the use of the new syscalls without building a custom
configuration. However, we could certainly build and use the wrapper routines now and update
them later.