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

On 10/19/2014 01:20 PM, Al Viro wrote:

On Fri, Oct 17, 2014 at 02:45:03PM -0700, Andy Lutomirski wrote:

quoted

For example, I want to be able to reliably do something like nsenter
--namespace-flags-here toybox sh.  Toybox's shell is unusual in that
it is more or less fully functional, so this should Just Work (tm),
except that the toybox binary might not exist in the namespace being
entered.  If execveat were available, I could rig nsenter or a similar
tool to open it with O_CLOEXEC, enter the namespace, and then call
execveat.

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.

Frankly, I wonder if it would make sense to provide something like
dupfs.  We can't mount it by default on /dev/fd (more's the pity), but
it might be a good thing to have.

What it is, for those who are not familiar with Plan 9: a filesystem with
one directory and a bunch of files in it.  Directory contents depends on
who's looking; for each opened descriptor in your descriptor table, you'll
see two files there.  One series is 0, 1, ... - opening one of those gives
dup().  IOW, it's *not* giving you a new struct file; it gives you a new
reference to existing one, complete with sharing IO position, etc.  Another
is 0ctl, 1ctl, ... - those are read-only and reading from them gives pretty
much a combination of our /proc/self/fdinfo/n with readlink of /proc/self/fd/n.

It's actually a better match for what one would expect at /dev/fd than what
we do.  Example:

Yes, it is really unfortunate that /proc/self/fd/* had the wrong
semantics for the start, due to then-existing implementation issues.

	-hpa