lkml.org 
[lkml]   [2013]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH signal#execve2] syscalls,x86: Add execveat() system call (v3)
On Sun, Jan 6, 2013 at 4:31 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> OK, now that sys_execve() unification has settled down, let's get back
> to this one. 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.

> 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).

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


\
 
 \ /
  Last update: 2013-01-08 14:21    [W:0.049 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site