Re: I'm done with O_CLOEXEC

[Chris Vine <chris cvine freeserve co uk>]

On Sat, 21 Mar 2015 06:59:41 +0100
Jürg Billeter <j bitron ch> wrote:
> On Sat, 2015-03-21 at 01:32 -0400, Ryan Lortie wrote:
> > It seems that this is a (slightly) recent addition.  It's
> > documented:
> >
> >        F_DUPFD_CLOEXEC (int; since Linux 2.6.24)
> >
> > so I'm sure we'll probably still need to write an ifdef with a
> > fallback...
>
> If you're referring to older Linux versions, I disagree. Even glibc
> has dropped support for Linux < 2.6.32, ifdef may be needed for other
> kernels, though, not sure.
>
> > The wider question about the usefulness of O_CLOEXEC still stands.
>
> I would keep using O_CLOEXEC as it's as close as we can get to the
> behavior that should have been the default: don't implicitly inherit
> file descriptors on exec.
>
> Maybe there are applications out there that rely on correct file
> descriptor flags and directly call fork/exec. You could try to
> convince them to switch to GSubprocess (or work around the issue in
> their own fork/exec code). However, as I think we all agree that
> O_CLOEXEC is the best default behavior, I don't see why we should
> break these applications.

Further, there are cases where porting to GSubprocess does not actually
do the job easily because (as I understand it) GSubprocessFlags
can be set to either close all descriptors on exec other than those for
stdin, stdout and stderr, or not close any descriptors on exec.

I have code which uses glib and also launches a helper child process
using fork/exec so that the helper process can run a VM with garbage
collection, for a particular purpose not relevant here.  The parent and
helper processes communicate via two pipes, which for various reasons
do not dup stdin and stdout on the helper process but act as
independent channels.  This means that the helper process's descriptors
for the pipes must be kept open on exec.  At present the code relies on
glib doing the right thing and looking after its own descriptors on
exec.  It would be a nuisance if that could not be relied on in the
future, which I think is your proposal.  (I understand your point that
that is not an assumption that users should be entitled to make, but it
IS the present behaviour and changing it in a stable series may
introduce breakage.)

However, if that is the proposal and you are going to go ahead with
it, can you provide a "close_all_except" convenience function to go
along with it which will walk open descriptors and close them but allow
the user to supply a list of user's descriptors which are not to be
closed, which the user can call between the fork and the exec, if that
can be done without calling async-signal-safe functions
(however, possibly walking the open descriptor list cannot be done
using only async-signal-safe functions, which would make it a
non-runner for multi-threaded programs).  Obviously the user could do
that herself, but at some inconvenience for code intended to run on a
number of platforms, some of which may have fdwalk() and some of which
may not, and for some of which fdwalk() may be async-signal-safe and
some of which may not.

Chris