Messages in this thread | | | Date | Tue, 6 Jul 1999 10:46:35 +0200 | From | Jamie Lokier <> | Subject | Re: [RFC][PATCH] scripts with stdin replaced |
| |
Richard Guenther wrote: > On Mon, 5 Jul 1999, Jamie Lokier wrote: > > > No, /proc/self/fd/3 is not an ordinary symlink although it looks like > > one to `ls'. It always reopens the correct file. Programs do not have > > to be changed, and it doesn't have the same race condition as passing > > the filename. > > Ok, if it is that simple, why do we pass the filename rather than > /proc/fd/something in binfmt_script? I can't see that it would break > anything, apart from some user not careing about procfs-support > (which could be wrapped by an #ifdef though).
It does changes the semantics a little: the script is opened twice (opening /proc/self/fd/something reopens the file), and the fd after opening is now be 4 instead of 3 (in the usual case).
It's probably best if you force "something" to be at least 3 -- to avoid breakage in the case that a script is invoked with stdin/stdout/stderr closed. (Bad, but hey).
Or the /proc/self/fd/script suggestion: make it another file in struct task just like /proc/self/fd/exe (the changes to procfs are obvious). Then the process sees _exactly_ the same fds as it's expecting.
> Expect a patch for this tomorrow. Btw. is this file-passing really > race-free? I.e. could we safely enable suid-bits for scripts with > /proc/fd passing?
There are often other reasons why scripts aren't safe. Depends on the interpreter. Environment variable problems are particularly common.
Probably the only safe well-known interpreter is perl, and that runs setuid scripts itself already.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |