3723edm@houxq.UUCP (E.MANTEL) (07/30/83)
On the UNIX systems I am familiar with (running USG 5.0), the PATH variable is set, both in /etc/profile and in login, to begin with a ':', meaning that the current directory is the first directory to be searched. It seems to me that this is a significant security hole, because it means that a user can set a booby trap by writing a shell that has the same name as a common command, but does something significantly different. Is it a common practice to have the default PATH begin with a ':'? Is there a real good reason to make this the default? Eli Mantel, houxq!3723edm, ABI ED&D Holmdel
bormanp@stolaf.UUCP (07/31/83)
As to having the current directory searched first in the PATH. Here at St. Olaf this is the default. As super-user this is not so good, so we switch to current directory last. Why not make this the default? Simple, as system programmers, we under stand about paths and such things, we know that if we write a program called 'mail', we must access it as './mail'. Try telling that to 3,000 students, most of them new users. They don't know what is out there, all they know is that they wrote a program called 'mail' which should be thier programming assignment, and when they run it, they can't imagine where all that other garbage came from. If you are paranoid, you may change it for yourself. Paul R Borman St. Olaf College ihnp4!stolaf!bormanp
bob@ucla-locus@sri-unix.UUCP (07/31/83)
From: Bob English <bob@ucla-locus> While it is possible to "fake out" a shell script in this manner, it isn't likely to help you much. In V7, for example, shell scripts do not run setuid, and anything you faked the script into doing, you could have done yourself anyway. On systems such as 4.1bsd, which do allow setuid shell scripts, the script should re-set all inherited parameters itself anyway. --bob--
gwyn@brl-vld@sri-unix.UUCP (07/31/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> I don't see any security problem with PATH=:/bin:/usr/bin etc. since only the user having programs with the same name as standard utilities in his current directory would be affected. However, the incautious super-user could get in trouble while rummaging around in other peoples' directories (serves him right). At BRL we set a different path like PATH=/etc:/bin:/usr/bin for su and super-user sh to avoid possible problems. It would generally be more efficient to have the system directories first in the search $PATH, since most commands are not found in the current directory. Less confusing, too. I think everybody ought to have a $PATH set in his .profile so he can do what he wants in this regard.
gwyn%brl-vld@sri-unix.UUCP (07/31/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> I firmly believe that all shell scripts should set their own $PATH before running any commands. We have almost as many $PATHs here as we have users, and some folks have programs in their $PATHs that have the same name as system utilities (yes, we know that sounds stupid, but there are good and sufficient reasons for it).
bob@ucla-locus@sri-unix.UUCP (08/01/83)
From: Bob English <bob@ucla-locus> I didn't say anything about the wisdom of trusting the user's path or environment, only about the security implications. --bob--
guy@rlgvax.UUCP (08/01/83)
On the UNIX systems I am familiar with (running USG 5.0), the PATH
variable is set, both in /etc/profile and in login, to begin with a
':', meaning that the current directory is the first directory to be
searched.
It seems to me that this is a significant security hole, because it
means that a user can set a booby trap by writing a shell that has
the same name as a common command, but does something significantly
different.
Is it a common practice to have the default PATH begin with a ':'?
Is there a real good reason to make this the default?
Yes, it is an almost universal practice. However, all USG systems I know
about DO protect the superuser; the default PATH for "root" is
/bin:/etc:/usr/bin (or some permutation thereof). I find it a pain when "root"
to have to say "./xxx" to run a test version of the program "xxx" (for obscure
reasons I do most development work on our System III systems as "root"), but
I have gotten into the habit of saying "./xxx". There is a good reason to
make it the default; people are used to it. If somebody feels like being very
security-conscious I feel it is THEIR responsibility to change their PATH.
I suspect it's somewhat of an issue like compulsory seat-belt laws or helmet
laws; some feel it is a person's responsibility to protect themselves and some
feel this protection should be required whether the person wants it or not.
(No flames please, this is NOT a statement of my views on seat-belt or helmet
laws.) As such, I guess it's really up to the system administrator; you
can always hack "/etc/profile", and anybody who doesn't like the PATH they've
been given can always replace it in their ".profile" anyway.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guyguido@mcvax.UUCP (08/02/83)
There is another point concerned that came to my mind when reading the
original article that Guy Harris doesn't touch. When a program which
lives, e.g., in /bin, uses other programs out there (say, "sort"), it
should either specify the full pathname (but surely this makes the program
less portable than desired), or it should explicitly SET THE PATH VARIABLE
before calling execvp() or system(). (I think you need some hacking
with extern char **environ to accomplish this in C.)
I saw this happen (rather harmless, though, in that case) where the "man"
program failed to work due to a shell script called "nroff" in someone's
private bin directory, which shell script called the real nroff after
some manipulations that used a file which had recently disappeared.
You understand this can happen to any program which carelessly uses
system(); and also easily to shell scripts (where the remedy is easiest,
though: start with PATH=/bin:/usr/bin or whatever you need).
Guido van Rossum, Math. Centre, Amsterdam
...!{decvax,philabs,ukc,...}!mcvax!guidovan@sequel.UUCP (08/02/83)
The discussion of whether to allow '.' in the $PATH reminds me of an incident that occurred where I used to work. When we first got our VAX/UNIX system up one of the people in charge of the system wrote two utilities which he called au (add user) and du (delete user) and which were very useful for doing those jobs. He placed these in the /etc directory. About 3 months later the other system administrator was trying to determine how much disk space was used by a certain user. So he typed 'du /user/user_name', unfortunately he was in /etc at the time and '.' was the first entry in his $PATH. When du didn't print the expected data on the screen he scratched his head and typed 'du /user/*', fortunately a few seconds into this he aborted the command. By that time though he had removed 4 users and their entire directory structures and partially removed a fifth (me). Needless to say du was quickly renamed 'removeuser' and the administrator paid the price by having to spend a couple of days restoring all our files from backup tapes. I hope that this illustrates the problem of having '.' at the start of your $PATH and the problem of not choosing resonable names for dangerous utilities. -- John Vander Borght ...pur-ee!sequel!van
greep@su-dsn@sri-unix.UUCP (08/04/83)
Your message (about the "delete user" program called "du") says more about the bad judgement used in having two programs with the same name than about the tradeoffs of different search paths.
john@genrad.UUCP (John Nelson) (08/07/83)
I really don't understand what all the hoopla is about! An unsophisticated user who never cd's to someone else's directory tree wishes to have the current directory searched FIRST for commands (so that his commands will override the system command names.) Anyone who is somewhat sophisticated will know about existing command names, and will generally avoid naming his own programs with a conflicting name! To avoid someone else renaming a standard command (or even to protect himself from accidently doing something as disasterous as the "du" delete user syndrome) all he has to do is put the "." directory LAST in his path! No one should ever have to type a command as ./command, even as a security measure, unless someone has stupidly named a program the same as a standard program! As for programs with standard names that create set-uid programs, if your current directory belongs to someone else, then the burden of being careful us up to YOU! If you execute programs on someone else's directory, you get what you deserve!