This is the mail archive of the
mailing list for the glibc project.
Re: [RFC/PATCH glibc 0/2] setting working dir in posix_spawn()
* Eric Blake:
> 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*).
But the pathname strings are copied, which is why I think there could be
> 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
I think for the _np version, we could rely on O_PATH and AT_EMPTY_PATH
for that, so no new flag would be needed there. O_PATH also avoids
pathname races and covers interaction with a chroot file action.
>>> 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