Re: I'm done with O_CLOEXEC
- Date: Fri, 27 Mar 2015 23:22:24 -0700
- From: "Jasper St. Pierre" <jstpierre@xxxxxxxxxxx>
- Subject: 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@xxxxxxxx> 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 . 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;
> socketpair (..., sv);
> g_subprocess_launcher_take_fd (launcher, sv, 3);
> g_subprocess_launcher_spawn (launcher, NULL, "/usr/bin/whatever");
> will put the sv 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".
gtk-devel-list mailing list