[PATCH] Use O_CLOEXEC for internal file descriptors

[Adam Jackson]

On Mon, 2012-02-27 at 18:11 +0100, Mark Kettenis wrote:

> Neither does OpenBSD.  And POSIX doesn't seem to mention it either.
> So this smells like a Linux-specific extension.  Or perhaps more
> accurately, a glibc-specific extension.

http://netbsd.gw.com/cgi-bin/man-cgi?fopen++NetBSD-current

I admit I hadn't checked OpenBSD or FreeBSD though.

> So you should change the
> #ifdefs around I think.  Or perhaps go the protable route using
> fileno(3) and fcntl(2).  I don't think atomicity is a real requirement
> here.

If you want the bug to be actually fixed instead of just almost fixed,
atomicity is the whole point and is absolutely a requirement.  Even if
we're assuming userspace threads like OpenBSD instead of real threads
like everything else, this is still a real race.

In case this isn't clear, the sequence looks like:

    int one = 1;
    FILE *fp = fopen(path, mode);
    int fd = fileno(fp);
    fcntl(fd, FD_CLOEXEC, &one);

And OpenBSD's thread scheduler alarm signal is perfectly capable of
firing (and switching tasks) between when fopen() returns and fcntl hits
the kernel, there's easily a few dozen instructions between those
points.  (Yes, I did go read the source.)

I'll concede that pci.ids isn't a hardware resource, and in that sense
it's not a huge deal whether fopen() works right.  But I would have
expected an OS that prides itself so much on using safe APIs all the
time to want to use safe APIs all the time.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120227/e4074c8a/attachment.pgp>