suid and shell scripts

utzoo!decvax!ucbvax!ihnss!ihps3!ih1ap!dab utzoo!decvax!ucbvax!ihnss!ihps3!ih1ap!dab
Thu Dec 10 12:56:42 AEST 1981


The reason for the lack of suid on shell scripts is that scripts are not
"exec"ed, they are "emulated".  The only person(s) that can change a userid
is the superuser and the operating system (are slaves persons?).  In order to
allow the shell to emulate the suid bit, it (the shell) would have to run as the
superuser.  I feel this is very dangerous and would really complicate the
already messy logic in the shell.  A solution that I've used is to create a
command by the desired name (eg fred) and the script by the name concatenated 
with ".sh" (eg fred.sh) both owned by the priveledged user (the person being
suid'ed to) with the "x" and "s" bits set as required (eg 1755 u=rwxs,go=rx).
The program grabs its first arg (arg[0]) and looks for a matching .sh file.
(Note the directory searched should be fixed for security reasons
(eg `logdir owner`/sbin)).  If one is found, the permissions and owner are
checked for security reasons.  If the suid permission is missing the suid is
undone and the shell invoked on the script.  If the permissions are ok and
the owner is correct (matches the current effective id) the shell is exec'ed
thereby inheriting the real and effective ids from the command. 

The reason for all the checking is that there need be only one such command
for each user and combination of suid/guid.  All the "fred"s (see above) get
link'ed to the one command.  Nice and flexible.  So far I've not been able to
violate this one security-wise except through carelessly written scripts.

		Dave Braun



More information about the Comp.unix.wizards mailing list