Re: [PATCH signal#execve2] syscalls,x86: Add execveat() system call (v3)

[David Drysdale]

On Tue, Jan 08, 2013 at 12:39:48PM +0000, Meredydd Luff wrote:
> On Sun, Jan 6, 2013 at 4:31 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > OK, now that sys_execve() unification has settled down, let's get back
> > to this one.

It's been a while, but I'd like to re-awaken this thread and patch;
given the radio silence I'm assuming that Meredydd didn't manage to
progress this any further.

> > The real problem is what you are doing with bprm->filename
> > and bprm->interp; blind use of ->d_name is completely wrong.
> ACK. I've blocked out tomorrow to dive in and figure out what I should
> be doing instead. My current plan is "look at how we get a string
> value out when readlink()ing /proc/self/fd/N, then copy that
> approach". Feel free to save me from wasting time if this is a bad
> idea.

Following Meredydd's plan, the procfs code (in do_proc_readlink()) uses
d_path(), so would using d_path(&file->f_path,...) on the file opened
from the (fd, filename) pair do what's needed here?  That looks like
it will be safe against renames (as it makes a copy of the name under
rcu_read_lock).
 
> > For what it's worth, how should it work for e.g. shell scripts?  That's
> > the main user of bprm->{filename,interp}, after all - other places are
> > either seriously exotic or are just using it for printks.
> >
> > For shell scripts, however, these guys are really used - we have the original
> > argv[0] removed and <shell name> <optional argument> <filename> pushed in
> > its place.
>
> As I see it, this is a question of how much can be supported.
> Fundamentally, a hash-bang interpreter is handed a filename. This will
> inevitably break in a world in which not everything you want to
> execute can be reliably named by a path in the interpreter's
> namespace. The demand for a "real" fexecve() argues that this world is
> desirable, and under those circumstances the best you can hope for is
> probably to fail gracefully, or at least predictably.
>
> > How will it work with execveat()?  If we have procfs in place, we can
> > cook an equivalent pathname (/proc/self/fd/<n>/<relative part of pathname>),
> > but then why not do just that in userland and be done with that?
> A pure-userland execveat() suffers all the problems of a pure-userland
> fexecve(). I think it's important to be able to use this in
> environments where /proc is absent or not trustworthy (weird embedded
> systems, sandboxes, etc).

As an aside, this is also why I'm interested in this patch -- in
particular for sandbox environments with /proc inaccessible.

Regards,
David

> If I'm understanding this right, the behaviour I was originally
> planning would leave the hash-bang interpreter with a pathname that
> "should" resolve to the script, barring jiggery-pokery with passing
> FDs between namespaces - but without the atomicity of the *at() call.
> This places execveat() into the category of "desirable things whose
> atomicity guarantees interact poorly with shell scripts" (a group with
> a long and [ig]noble history).
>
> I suppose the munging could be conditional: "If /proc is owned by root
> and mounted as procfs, we'll give you a /proc/self/fd/... path.
> Otherwise you're on your own and getting whatever
> readlink(/proc/self/fd/<n>) would have given you." But that would
> still require the kernel knowing something about the filesystem
> layout.
>
> Either way, it seems, we leave a rake in the grass for somebody...
>
> Meredydd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/