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

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_addfchdir(&act, mydir);
posix_spawn_file_actions_addopen(&act, 4, "file", mode, 0);
posix_spawn_file_actions_addfchdir(&act, 5);
posix_spawn_file_actions_addclose(&act, 5);

Is it possible to choose an appropriate value for the directory descriptor automatically?

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_adddup2(), or 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 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?


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