$PATH Question.

[david_252]

Team:

Here is the scenario

wePATH=$APPPATH/usr/bin:;export PATH have on machine A
PATH=$APPPATH/usr/bin;export PATH
On machine B (note the missing :)
what is the difference and impact of not having this

Thanks
David.

[Robert-Jan Goossens]

Hi David,

In your case none, if you add an other path you have to use : as a seperator.

Robert-Jan.

[James R. Ferguson]

Hi David:

The ":" is a delimiter character for parsing the component fields. Its absence (or presence) at the end of the string doesn't matter.

Regards!

...JRF...

[Christopher McCray_1]

Hello,

In the first example, the : is not needed because you don't have another path to enter. The : is nothing more than a separator.

Chris

[Bill McNAMARA_1]

I don't see a problem here unless of course the : is missing between
$APPPATH and /usr/bin
ie:
$APPPATH:/usr/bin

!
The : is not required at the end.

Later,
Bill

[John Poff · Accepted solution]

Hi,

Good question. I played with it a bit, and it looks like the colon on the end does make a difference (at least with the regular PATH environment variable, not sure if your APPPATH works the same way). See, the colon is the field separator for the PATH variable. With a colon at the end, you are specifying a null field, which PATH interprets to be the current directory.

To test it, I created a script (mytest) with executable permissions in my home directory. I set my path to the default:

export PATH=/usr/bin

and tried to find my script:

# type myscript
myscript not found.

(Yes, I did it as root, but it is on a brand new test box!) Now, set the PATH with the colon on the end:

# export PATH=/usr/bin:
# type myscript
myscript is /root_home/myscript

So it makes a difference with the PATH variable. If your APPPATH behaves just like the PATH does, the difference is that the machine with the colon on the end of APPPATH will include the current directory, while the other APPPATH won't.

JP

[Darrell Allen]

Good job John. Your testing is verified by "man sh-posix" and "man sh-bourne" in the "Execution" section:


Note that the current directory is specified by a null path name, which can appear immediately after the equal sign, between colon delimiters, or at the end of the path list.


I always thought a "." in PATH specified the current directory.

Darrell

[John Poff]

Thanks Darrell. I never knew that until I just tried it, and it is kind of scary! As you said, we all know to avoid the '.' in our PATH variable, but it looks like a spare colon has the same effect. Kind of a nasty little trick for a hacker. I played with it a little more, and just having a spare colon buried in the middle of your PATH variable does the same thing. Ouch!

Now I've gotta go check all the PATH settings for root on all my boxes. ;)

JP

[James R. Ferguson]

Hi John & Darrell:

Ditto for me, too! Nasty. After your post, John, I tried the same test and got the same results as you. I looked up the man pages for 'sh-posix' and as Darrell quoted...well, I too, thought that dot (.) was the only problem.
Fortunately my boxes contain properly formatted PATH variables!

Regards!

...JRF...

[John Poff]

Hello again,

It gets even better. I checked the PATH setting for root on all my boxes for the colon at the end of the path or in the middle of the path. I was pretty sure I was ok. Wrong! I found two boxes where the PATH had a double colon in the middle of the PATH setting. Here is a portion of the .profile for root on both boxes:


PATH=/usr/sbin:$PATH:$OV_BIN:/sbin:/root_home/bin

The $OV_BIN environment variable was never set when .profile was executed, so the PATH wound up with :: in the middle. I tested it by doing a 'type somescript' where 'somescript' was an executable script in root's home directory, and sure enough it found it.

I took the HP-UX Operating System Security class a couple of years ago. I dug out my class notes just to see if we covered the issue. There was a slide warning about putting '.' in your path and how it opens up the danger for trojan scripts, but nothing about the colon issue. Maybe they can add this to it some day.

JP

[Bill Hassell]

Yes, there are 3 circumstances where PWD (current working directory) will function based on $PATH: two colons, colon-dot-colon, and colon at the end. However, from a security point of view, $PATH needs a *LOT* scrutiny. You should check:

- $PWD not in $PATH
- *NO* $PATH directory should ever be world writable
- ideally, no directory should be group writable either
- no PATH entry should be a symlink

and for good measure:

- no duplicates in the PATH (HP-UX will search again and again...)
- remove non-existant directories in $PATH
- check that a PATH entry is really a directory and not a file

All of this is checked in the attached script for both /etc/PATH as well as the current user's $PATH

[david_252]

Thanks To all. That was a great lesson.

Thanks
David.

[H.Merijn Brand (procura]

To make my $PATH fast, and safe for this last security hole, I do in my .tcshrc [ (t)csh syntax ]:

> setenv PATH `perl -e '($P=$ENV{PATH})=~s://+:/:g;$P=~s/::+/:/g;$P=~s,(:/usr/bin/X11)(?=:),$1R6$1,;foreach(split m/:+/,$P){-d&&$P{$_}++==0&&push@P,$_;}print join":",@P;'`

It strips non-existing or duplicate folders.
For even more security, you can do something like

> setenv PATH `perl -MCwd=abs_path -e '($P=$ENV{PATH})=~s://+:/:g;$P=~s/::+/:/g;$P=~s,(:/usr/bin/X11)(?=:),$1R6$1,;foreach(split m/:+/,$P){-d&&$P{abs_path$_}++==0&&push@P,abs_path$_;}print join":",@P;'`


Easy to change to strip '.' too:

> setenv PATH `perl -MCwd=abs_path -e '($P=$ENV{PATH})=~s://+:/:g;$P=~s/::+/:/g;$P=~s,(:/usr/bin/X11)(?=:),$1R6$1,;foreach(split m/:+/,$P){m:^[/.]+$/&&next;-d&&$P{abs_path$_}++==0&&push@P,abs_path$_;}print join":",@P;'`

[H.Merijn Brand (procura]

Bill, your script ain't safe enough:

export PATH=/usr/bin:./:../.:./././.:.:

it will not detect ./ (trailing slash)
my final perl snippet does:

m/^[./]+$/&&next;

will skipp all path elements consisting of dots and slahes only