Web lists-archives.com

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:
> 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
> 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

gtk-devel-list mailing list