Messages in this thread |  | | From | Meredydd Luff <> | Date | Tue, 8 Jan 2013 12:39:48 +0000 | Subject | Re: [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
|  |