DarkSoul <darks...@darkbsd.org> wrote: > Anthony Pankov wrote: > > SGID/SUID bits don't work with shell scripts, do they? > > They don't. > > ... if they were applied, the following would occur : > - execve() syscall reads your script's shebang line, and > the script interpreter is executed, receiving the specified > arguments along with the script name. > - The interpreter then open()s the script file to read it, > and run the code. > > The problem you then are faced with, is that you have a time > frame defined by the moment between the aforementioned execve() > and open(), during which it could be possible to unlink/move/ > whatever the shell script the interpreter is going to open. > > You guess where this is going, you have no absolute way of > guaranteeing you are executing the file you initially planned > on opening because execution/opening/reading is not, and can't > be done atomically for shell scripts.
In principle, it should be possible to fix this exposure by improving the interface between execve() and the interpreter: The execve() syscall already has the script file open to read the shebang line. Leave it open, and ensure that the interpreter receives the open descriptor as fd#3 just as 0, 1, and 2 are already used for stdin, stdout, and stderr. An interpreter supporting this approach would check whether stdscr (fd#3) is already open, and if so read from it instead of open()ing the script file. This should ensure that the script which gets executed is the same inode on which execve() saw the SGID/SUID bits set, even if the filesystem has been changed by the time the interpreter has gotten started. It would be the responsibility of whomever decided to set the SGID/SUID bits on a particular script to ensure that the interpreter involved supports the mechanism. I vaguely recall having seen a similar (or even identical) approach suggested some years ago. It may even have been implemented in some variant of Un*x. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
