This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
*some* ambiguity.

> 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).

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]