Re: env -C lacks fchdir support

[Pádraig Brady]

On 10/09/18 08:30, Eric Blake wrote:
> On 9/9/18 7:01 PM, Pádraig Brady wrote:
>> On 07/09/18 08:24, Eric Blake wrote:
>>> There are cases where you cannot directly change directory to a given
>>> location via a path name, but where you can hold an fd to that directory
>>> and where fchdir() will work. Since we've already added 'env -C' as an
>>> extension for chdir, should we add a counterpart extension that permits
>>> fchdir to an inherited fd, even for systems that lack /proc/NNN/fd/MMM?
>>
>> Maybe. Do you have concrete examples for where this might be useful.
> 
> Not the cleanest, but I'm playing with ideas with using 'env' to 
> workaround a lack of posix_spawn_file_actions_addchdir[_np]() in libc. 
> That is, I'm trying to see if it makes sense for attempting to convert 
> this pseudocode:
> 
> fork()
> fd = openat(dir, "relative", flags)
> dup2(fd, 0)
> close(fd)
> fchdir(dir)
> exec("program", (char *const[]){"program", "args", NULL}, env)
> 
> into:
> 
> posix_spawn_file_actions_init(&act)
> fd = openat(dir, "relative", flags)
> posix_spawn_file_actions_adddup2(&act, fd, 0)
> posix_spawn_file_actions_addclose(&act, fd)
> posix_spawnp(&pid, "env", &act, NULL,
>    (char *const[]){"env", "--fchdir", to_string(dir),
>       "program", "args", NULL}, env)
> posix_spawn_file_actions_destroy(&act)
> 
> although right off the bat, I'm seeing an issue that you can set 
> FD_CLOEXEC on dir so that it doesn't leak into the child via fork/exec, 
> but it MUST leak into 'env --fchdir NNN', so we'd also need a way to 
> tell env whether to further close the fd before calling the wrapped program.
> 

Seeing that I'm inclined to think coreutils should restrict
themselves to file name level operations, leaving descriptor
level to lower level libs.

cheers,
Pádraig