Re: [RFC/PATCH glibc 0/2] setting working dir in posix_spawn()

[Florian Weimer <fweimer at redhat dot com>]

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, );
> close(scratch_fd);

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?

Thanks,
Florian