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 09/10/2018 06:30 PM, Eric Blake wrote:
On 9/9/18 3:34 PM, Florian Weimer wrote:
On 09/08/2018 12:54 AM, Eric Blake wrote:
Also, I've realized that we do NOT need
posix_spawn_file_actions_addopenat(). The main benefit of openat() is
that you can redirect relative file names according to an fd of your
choice, without affecting global state. But during posix_spawn(),
there are no other threads competing for global state (if you are
doing a library implementation where the chdir() is done between
fork() and exec()), so:
openat(mydir, "file", mode);
can be decomposed to:
posix_spawn_file_actions_addopen(&act, 5, ".", O_RDONLY|O_DIRECTORY, 0);
posix_spawn_file_actions_addopen(&act, 4, "file", mode, 0);
Is it possible to choose an appropriate value for the directory
Not that I know of. But it's tougher than it looks - my initial thought
was "what about a magic negative number" that says to auto-allocate at
the next free fd (the way AT_FDCWD is a magic number) - but since the
allocation of fds is done at a later point (the posix_spawn() call) than
the addition to file_actions (the posix_spawn_file_actions_addopen()),
there is no way to predict WHAT that fd will actually resolve to, and
thus no way to reuse that fd in posix_spawn_file_actions_addfchdir(),
posix_spawn_file_actions_addclose() as needed. In other words, by the
time you're using posix_spawn(), you're already stuck with having to
micro-manage your fds - and if you want to avoid closing something
important by accident, you practically have to do:
scratch_fd = open("/dev/null", O_RDONLY|O_CLOEXEC);
posix_spawn_file_actions_addopen(&act, scratch_fd, ...);
posix_spawn(, &act, );
Presumably you could also open a descriptor for "." in the parent. But
all this looks a bit horrible, so I'm leaning towards adding additional
functions where this makes sense.
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.
What about support for AT_EMPTY_PATH, for upgrading an O_PATH
descriptor? I think this operation still needs openat.
O_PATH and AT_EMPTY_PATH are Linux/glibc extensions not in POSIX. So
yes, they are worth thinking about in terms of what glibc should
provide, but I'm not sure if they are sufficient on their own to require
POSIX to worry about posix_spawn_file_actions_addopenat(), but rather
might argue that glibc should add posix_spawn_file_actions_addopenat_np().
Right, I didn't see the Cc to the Austin Group list. I've dropped it
because it rejects mail with a rather rude message.
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?