In message <m2bqlctbce.fsf@[...].lan> , Piet van Oostrum wrote:

>  Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> (LD) wrote:
>  In message <m2hcv651ta.fsf@[...].nl>, 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