Please do NOT use "/bin/test" as a command name

[Bill.Stewart.4K435.x0705]

In article <6223 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
>> 	Also, I would love to try to break into a system kept secure by your
>> shell scripts which do not contain absolute path names.  I would do exactly
>> what you suggest - substitute my own versions of rm, mv, etc...
>
>Wouldn't help, since all those shell scripts start with the magic line:
>
>	PATH=/bin:/usr/bin ; export PATH
>
>which solves the problem without requiring hardwired path names everywhere.
>Also, it solves the problem for everything invoked by the shell script,
>rather than just for the shell script itself.

Henry and Ian are usually right :-), but ......
Actually, it has the potential for BREAKING almost everything invoked
by the shell script, though not the shell script itself!  If you do

	PATH=/bin:/usr/bin:$PATH: ; export PATH

(perhaps with /usr/ucb/bin or /usr/lbin wedged in there) then the
script can call other scripts that depend on the user's path.  You do
need to protect all the standard-location commands, but you should also
allow the user's path to remain.  (I once saw an in-house shell
tutorial thatt showed a .profile with PATH=:/bin:/usr/bin:/4513/fred/bin: -
the user had tried it out and wondered why lots of useful commands
didn't work any more.)

There are a few other fun commands to have local versions of.  One of
my users wrote a "sort", in Fortran.  After he got it to compile, he
decided to add some features, and "f77 sort.f" died with ugly errors.
Seems the system V f77 compiler used "sort" to help with symbol tables,
and his sort routine didn't take the same arguments as /bin/sort.

-- 
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs