In message <[EMAIL PROTECTED]>, Piet van Oostrum wrote: > Lawrence D'Oliveiro <[EMAIL PROTECTED]> (LD) wrote: > In message <[EMAIL PROTECTED]>, Piet van Oostrum wrote: > >> The scenario is as follows: Suppose the script starts with the line: >> #!/usr/bin/python >> >> (using #!/usr/bin/env python would be disastrous because the user could >> supply his own `python interpreter' in his PATH.) >> >> Now a malicious user can make a link to this file in his own directory, >> e.g. to /Users/eve/myscript1. Because permissions are part of the file >> (inode), not of the file name, this one is also suid. >> >> Now she execs /Users/eve/myscript1. The kernel, when honoring suid >> scripts, would startup python with effective uid root with the command >> line: /usr/bin/env /Users/eve/myscript1 >> >>LD> No it wouldn't. This security hole was fixed years ago. > > How?
Systems which allow set-uid scripts also usually support referring to open file descriptors n via a pathname like /dev/fd/n. This might be done by mounting a special pseudo-filesystem (fdfs) on /dev/fd. (This was how I remember it being done on DEC UNIX.) So when a the kernel detects that an executable file is actually a script, it opens the script file on some file descriptor n, and passes the name /dev/fd/n to the script interpreter, instead of the original script pathname. That way, there is no opportunity for deceiving the process into executing the wrong script with set-uid privileges. -- http://mail.python.org/mailman/listinfo/python-list
