[RFC/PATCH glibc 0/2] setting working dir in posix_spawn()

Eric Blake eblake@redhat.com
Wed Sep 12 15:53:00 GMT 2018


On 9/12/18 8:14 AM, Florian Weimer wrote:

> 
> One problem with *at is whether the directory/base descriptor should 
> reference the file description at the time posix_spawn was called, take 
> the effect of previous file actions into account, or use the file 
> description at the time posix_spawn_file_actions_add*at is called.  I 
> think the last option is quite problematic, but I don't know which of 
> the previous options is preferable.

All other file_actions_add* are documented to act in strict sequential 
order, taking into account any actions accomplished during posix_spawn() 
prior to reaching that action.  I think it is the most straightforward 
to document that everything is in relation to the current value of an fd 
at the time the call is reached (which, like _addopen, _adddup2, and 
_addclose, is NOT necessarily the value of that fd at the time of the 
file_actions_add*).

It might also be possible to have a flag argument to 
posix_spawn_file_actions_addopenat[_np] that says to do enough 
preprocessing at the time the action is added to the list to perform 
immediate relative resolution (perhaps by storing an absolute filename 
into the file action so that the actual action during posix_spawn() is 
no longer relative) - where the _addopenat fails if the translation from 
relative to absolute cannot be performed (whether from ENOMEM or otherwise).

>> Also, note that http://austingroupbugs.net/view.php?id=411 is also 
>> somewhat relevant, which states:
>>
>>> At line 46976 [XSH posix_spawn_file_actions_adddup2], add a sentence:
>>>
>>> If fildes and newfildes are equal, then the action shall ensure that
>>> the FD_CLOEXEC flag of fildes is cleared (even though dup2( ) would
>>> leave it unchanged).
> 
> Do we have a glibc bug for this?

I didn't see one, so I filed 
https://sourceware.org/bugzilla/show_bug.cgi?id=23640

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



More information about the Libc-alpha mailing list