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()
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
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
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org