Re: I'm done with O_CLOEXEC

[Ryan Lortie <desrt desrt ca>]

On Fri, Mar 20, 2015, at 20:29, Christian Hergert wrote:
> What I would welcome, is a function that says "glib, close all FDs you 
> know about or that you created". If all the libraries did that, at least 
> it would be possible for applications to maybe, sorta, do the right 
> thing. (That would push the synchronization responsibility during 
> fork()/exec() to the application).

I don't think this is the correct approach.

The application should not have to be aware of what GLib is doing, or
even that it is using GLib at all (if GLib is pulled in by some other
intermediate library).  Much less for any other libraries that it may be
using.

What the application should be aware of is simple: what does it want to
pass to a process that it is spawning?  Anything that it doesn't want to
pass should be closed (after the fork, before the exec).

There are many ways of accomplishing this.  Some systems have an
fdwalk() [read: "foreach open fd"] call designed to help you do this. 
On Linux the common idiom is to iterate /proc/self/fd/, closing as you
go.  On other systems which lack either of these, it's still possible to
obtain the maximum possible file descriptor number and simply use a for
loop to close them all (even if you call close() on some fds that are
not really open).

[[ As an aside: it would be great if we had a variant of execve() that
took an array of fds.  The new process image would end up with the fds
in that array remapped as fd 0, fd 1, fd 2 (and so on) according to
their array position.  The truth is, however, with the "walk and close
all fds" tricks that are already widely known and practised, this would
only be a convenience. ]]

Cheers