SGID/SUID on scripts

[Lowell Gilbert]

perryh at pluto.rain.com writes:

> DarkSoul <darksoul at 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.

That's clever, but how would it work in practice, while common shells
and scripting languages may not implement their side of it?