[net.unix-wizards] kernel recognizing #! scripts

richa@ios.UUCP (Rich Altmaier) (03/09/84)

One advantage to having the kernel recognize #! scripts is
that set-uid/gid mode works.  Just as with a binary, the
kernel recognizes this mode and starts the shell or whatever with
appropriate effective uid/gid.  On 4.1bsd, scripts without
#! ignore set-uid mode.

I don't think a shell could give the same functionality, with the exec()
fail - recognize script approach.  The set-uid mechanism is
simple and useful, and I expect this is exactly why the kernel
was made to recognize #!.

	Rich Altmaier, Integrated Office Systems.
	decwrl!ios!richa

ado@elsie.UUCP (03/09/84)

	One advantage to having the kernel recognize #! scripts is
	that set-uid/gid mode works.  Just as with a binary, the
	kernel recognizes this mode and starts the shell or whatever with
	appropriate effective uid/gid.  On 4.1bsd, scripts without
	#! ignore set-uid mode. . .
		Rich Altmaier, Integrated Office Systems.
		decwrl!ios!richa

Note, however, that in a binary program you can issue a system call to
reset the user (or group) id to the "real" (as distinct from the effective) id.
I've yet to learn of a way to do this in shell scripts.  Maybe the unavailable
korn shell supports it.
--
The "unix" in "net.unix-wizards" is a down-cased variant of "UNIX" (please note:
all UPPER CASE), which is a Bell Labs trademark.
-- 
UUCP:	decvax!harpo!seismo!rlgvax!cvl!elsie!ado
DDD:	(301) 496-5688

jdb%s1-c@sri-unix.UUCP (03/10/84)

It is true that the "magic number" #! allows setuid/setgid
command files to be executed.  However, I do not trust them.  This
is not superstition; I know of a couple of security holes that can
result.  While there are ways to close these particular holes
I'm not confident enough of the underlying mechanism to believe
that there aren't other problems I haven't thought of.

I recommend the use of #! for non-setuid command files; it is very
useful for "make" and "awk".  If you want something to be setuid,
though, I suggest that you use a real binary program.
--
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@s1-c	UUCP: ...!decvax!decwrl!mordor!jdb