Web lists-archives.com

Re: I'm done with O_CLOEXEC


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

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".

gtk-devel-list mailing list