Re: I'm done with O_CLOEXEC

[Ryan Lortie <desrt desrt ca>]

hi,

On Sat, Mar 21, 2015, at 01:19, Jasper St. Pierre wrote:
> Right now, we use raw fork/exec in mutter where we need to do some tricky
> management and explicitly leak an FD into the correct place [0]. Does
> this
> mean that from now on, glib might leak an FD and we need to be prepared
> to
> handle that? Refactoring the code to use a child setup func and using
> g_spawn isn't quite really what I want to do (can I even leak an FD made
> with socketpair through in that case?), but I want to be aware of what
> might break in the future, and whose bug it should be.

I recommend using GSubprocess.

g_subprocess_launcher_take_fd() lets you give an fd (along with a
target_fd number).  This fd will appear in the newly-spawned process as
the "target" number you gave.  This is what I mean by code that spawns
processes having explicit control over what they do.

For example:

  int sv[2];

  socketpair (..., sv);
  g_subprocess_launcher_take_fd (launcher, sv[1], 3);
  g_subprocess_launcher_spawn (launcher, NULL, "/usr/bin/whatever");

will put the sv[1] end of the socket pair into the launched process as
fd 3.

> I know it's difficult to set a policy about this, but is there anything I
> can do to prevent too much damage in the future? If I file a patch
> against
> glib for where it might not set CLOEXEC with an easy flag the syscall,
> will
> you accept it, or are you going to reject it to stop me from relying on
> CLOEXEC?

I'm not sure.  It probably depends on the outcome of this thread.  I'm
leaning towards "we won't do it if it complicates the code".

Cheers