Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!ncar!oddjob!uxc!uxc.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!kai
From: kai@uicsrd.csrd.uiuc.edu
Newsgroups: comp.unix.wizards
Subject: Re: show me
Message-ID: <43200023@uicsrd.csrd.uiuc.edu>
Date: 5 Aug 88 01:24:00 GMT
References: <43200021@uicsrd.csrd.uiuc.edu>
Lines: 43
Nf-ID: #R:uicsrd.csrd.uiuc.edu:43200021:uicsrd.csrd.uiuc.edu:43200023:000:2031
Nf-From: uicsrd.csrd.uiuc.edu!kai    Aug  4 20:24:00 1988


I did not want to hear about what can be done once you've got superuser
priviledges.  I've already got superuser priviledges (being system
administrator for three systems).  I wanted to hear why I should avoid
using setuid shell scripts so that other people don't get to be.  Thanks
to those who responded with helpful reasons.

In the interest of informing system administrators about this very real
hazard, here's a summary:


1)  C-shell scripts execute the ".cshrc" file of the person executing the
script (as opposed to the ".cshrc" file of the user the script is set to)
unless the "-f" switch is used (as in "#!/bin/csh -f").

2)  C-shell and Bourne Shell scripts execute the ".login" or ".profile"
file belonging to the person executing the script if argv[0] = "-".  A
simple one line C program can be used to do this.  There is NO workaround
for this.

3)  The wrong commands might be called if the person executing the script
modifies the PATH environment variable before calling the script.  This
can be worked around by setting the PATH in the script.  This is an oft
seen problem with non-set[gu]id shell script, too, although it usually
isn't deliberate.

4)  The wrong commands might be called if the person executing the script
modifies the IFS environment variable before calling the script.  Some
system's C and Bourne don't use the IFS passed in the environment, but not
all do.  If yours does, there is no workaround (if IFS contains the equals
sign, IFS=" \t\n" will not reset it, but will instead call the external
command IFS).


Reason #2 above is enough to convince me that C and Bourne shell scripts
aren't worth the hassle.  I can't say the same for Perl scripts, since
Perl was designed for script usage, not interactive use.  Reasons #3 and
#4 could cause problems if external commands are called, but can easily be
worked around by setting them in each script.


	Patrick Wolfe (pwolfe@kai.com, kailand!pwolfe)
	System Manager, Kuck and Associates, Inc.
	"Don't you wish real life had a ^Z command?"