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/