Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call

[Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]

On Sun, Oct 19, 2014 at 01:37:54PM -0700, Andy Lutomirski wrote:
> > The question I hadn't seen really answered through all of that was how to
> > deal with #!...  "Just use d_path()" isn't particulary appealing - if that
> > file has a pathname reachable for you, you could bloody well use _that_
> > from the very beginning.
> 
> Does this matter for absolute paths after #! (or for absolute paths to
> ELF interpreters)?  Does anyone use relative paths there?

It's not about what's after #!; it's what we *append* to what's after #!
that is interesting.  Recall how #! works - we turn execve() of something
that starts with e.g. "#!/usr/bin/make -f\n" into execve of /usr/bin/make,
with (/usr/bin/make, -f, name of that file, argv[1]..argv[argc]) as
arguments list.  With make(1) doing opening and reading the file, as it
would for any makefile.  Or /bin/sh opening and reading the script, etc.

Pathname of interpreter is a non-issue (and ELF ones don't go anywhere
near that path anyway).

> Does execve("/proc/self/fd/N", ...) not work correctly now?

Yes, it does.  And if procfs is there, this syscall is completely pointless.
The main argument in favour of adding it to the kernel (rather than doing
in userland) has been "but what of the people who don't want procfs mounted
in there?".

> Presumably relative paths should be relative to the execed program, or
> maybe there should be a flag to execveat that disallows that behavior
> entirely, or maybe it should never work, even through /proc.  I don't
> really like the idea that an fd pointing at a *file* should allow
> access to its directory.

Huh?  What are you talking about?  And who the hell cares whether it's
absolute or relative?

> I'm not convinced that these semantics are better than /proc/self/fd's
> in many contexts.  I don't really like the idea that catting some file
> can *change* the position of one of my open file descriptors.

Er...  You do realize that if descriptor refers to the same file,
cat <&<that descriptor> will change position of your other descriptor,
right?  BTW, on *BSD /dev/stdin *does* have a dup()-style semantics.
They do it at the price of very convoluted code in their VFS, but that's
how it works there.  And in Plan 9, and (AFAIK) in Solaris...