Re: I'm done with O_CLOEXEC

Thanks. I have refactored this code to use GSubprocess:

Not overly happy with the hardcoded fd assignments, but it's not the
end of the world.

On Fri, Mar 20, 2015 at 10:28 PM, Ryan Lortie <desrt desrt ca> wrote:

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
mean that from now on, glib might leak an FD and we need to be prepared
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
glib for where it might not set CLOEXEC with an easy flag the syscall,
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".



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]