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

[Chris Torek]

[PATH=/foo:/bar:/baz; export PATH]

In article <11193 at ucbvax.BERKELEY.EDU> cc-06 at ucbcory.BERKELEY.EDU
(Ilya Goldberg) writes:

> no one is trying to save cpu time by doing what they are doing.
> Just think of what would happen if the user doesn't have the right
> things in his/her path variable or no path at all!

Then nothing works at all, so why worry about that case?

> Also, I would love to try to break into a system kept secure by
> your shell scripts which do not contain absolute path names.

Who uses setuid shell scripts?  (Actually, I have on one machine
a shell script that is run privileged by a separate setuid C program,
which verifies the user first; and the script is relatively careful.)

> I would do exactly what you suggest - substitute my own versions of
> rm, mv, etc so that when a set-u-id root shell script tries to
> execute one of those, UNIX will take the version in my directory.

Putting in full path names is not the solution---suppose I change $IFS?

> So, when writing programs/shell scripts which call other programs
> do include full path names, preferrably in a place where they are
> easily found and can be easily modified (e.g. ".h" files).

Include *paths*, not full path *names*.  There is a difference.  See
`man execvp' and `man execlp'.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu