Bug 15881 - strange PATH settings
Summary: strange PATH settings
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: util-linux   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-09 18:31 UTC by Michael Redinger
Modified: 2007-04-18 16:28 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-14 18:58:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michael Redinger 2000-08-09 18:31:10 UTC
Just noticed some strange things doing an echo $PATH (from different

non-root user


root (su - from non-root user)

non-root user ( su - from non-root user to root, su - to non-root user)

rsh non-root user

rlogin non-root user

Some notes:

- the PATH of normal users should probably end with ":" to include the
  current directory. This is one of the most FAQ ...

- I think it should be /usr/bin/X11, not /usr/X11R6/bin (for compatibility
  reasons with other Unix Platforms)
- for non-root it should be  

- the root path is really messed ... should read:

- su - does mess up your path

- rsh should have better path settings ... at least include /usr/bin/X11
  (how is this done? pam_env?)

Think this is a MUST-FIX.

Comment 1 Bernhard Rosenkraenzer 2000-08-09 18:44:37 UTC
The initial paths are set by login (util-linux)

Comment 2 Michael Redinger 2000-08-09 21:55:58 UTC
Right, but they are treated quite differently by the different programs. Eg.
some programs do read profile, some don't. Same for bashrc. I think the path
should be right before these files are accessed. I had a very quick look at
/etc/security/pam_env.conf (used by pam_env), and it looked as if this could
some of these problems (could be wrong, but it looked nice .. :) ).

Comment 3 Michael Redinger 2000-08-13 16:15:12 UTC
Same in RC1, changing version.

There's a bug that's possibly related to this - see bug #16004

Comment 4 Glen Foster 2000-08-13 18:00:24 UTC
I agree that paths should be consistenty set given various methods to obtain
access to a specific user-ID.  I do not agree, however, with some of the
specific recommendations made.  Regardless, this is an issue that could be much
farther-reaching than just in bash or with /etc/profile, and should be deferred
to the next release of Red Hat Linux.  There's simply not enough time to
completely investigate this defect and make a complete change prior to releasing
Winston.  Marking as DEFERRED.

Comment 5 Michael Redinger 2000-12-22 20:34:55 UTC
Same in Florence Beta 1, therefore reopening.

Some test results (note that I couldn't test rsh yet as it doesn't work for me.)

xterm -ls:


xterm -e su -:

xterm -e su:

xterm -e su -, then su - to normal user:


Comment 6 Gerald Teschl 2000-12-28 12:56:04 UTC
This should really be fixed! You could at least apply the patch from
below /etc/profile and make similar changes to the other init scripts.

--- profile.orig        Thu Dec 28 13:41:11 2000 
+++ profile     Thu Dec 28 13:42:49 2000
@@ -3,7 +3,10 @@
 # System wide environment and startup programs
 # Functions and aliases go in /etc/bashrc
+if echo $PATH | grep -vq /usr/X11R6/bin
+        PATH="$PATH:/usr/X11R6/bin"
 ulimit -S -c 1000000 > /dev/null 2>&1
 if [ `id -gn` = `id -un` -a `id -u` -gt 14 ]; then

Comment 7 Erik Troan 2001-02-09 00:06:20 UTC
The grep suggestion is in the current setup package, and correct.

Some of this is invalid:

	1) /usr/X11R6/bin is the canonical location, and /usr/bin/X11 is a
	   compatibility symlink (according to FHS), so we do this correctly

	2) Leaving . out of users paths is quite concsious, and intended to
	   prevent users from running the wrong programs inadvertently
	   there's pretty widespread agreement this is a good security policy

	3) are paths are essentialy the ones you suggest, though the order
	   differs a bit

	4) the rsh/telnet paths look okay to me.... (sorry)

I think the most obviously correct part of this has been addressed in the setup
package, and I'm going to close the rest of this.

Comment 8 Michael Redinger 2001-04-02 09:54:59 UTC
Reopening this for RC2, QA0328:

I think this is really broken - the path settings are inconsistent, some are
definitely wrong:


login as normal user on console:

(looks good!)

xterm -ls as normal user in KDE:

(the user's home directory is listed twice; local/bin should be the first bin
directory listed)
(see "rsh localhost as normal user")

login as root on the console:

(/usr/local/sbin, /usr/sbin and /sbin are listed twice; /root/bin shouldn't
be there - your mileage may vary ...)

login as normal user, then su - to root:

(quite different, right? This is _really_ broken)
(please note /usr/bin/X11:/usr/X11R6/bin)


login as normal user, then su to root:

xterm -ls in kde, then su to root:

(the sbin directories,except for kerberos, are missing; include them or
remove /usr/kerberos/sbin, too.; note that the user home directory is now
listed twice.)


rsh localhost as normal user:

(this one's fine ...)

rsh localhost as normal user, then su to root:

(similar to "su to root", but much better ...)


rsh localhost as root:

(again - some sbin directories are listed twice.)


Comment 9 Michael Redinger 2001-07-07 17:09:32 UTC

Looks much better in Fairfax. But there are some issues left:

- every login method has a different path (at least the order differs)

  (well, ssh and rlogin are identical with console login, but that's not

  really surprising ...)

- there are many duplicate entries

- console root login: /usr/local/sbin, /usr/sbin and /sbin are listed twice

- kde root login (no, I don't use this!):

      /sbin and /usr/sbin are listed twice

- gnome root login (neither this one ...):

      /sbin and /usr/sbin are listed twice

- rsh is very different, as usual ... it simply sets the path to

      /usr/bin:/bin (yes, it's hardcoded ...). :(

The gory details: ;)


























rsh (rsh host 'echo $PATH'):





Comment 10 Elliot Lee 2001-07-17 21:54:53 UTC
. Multiple entries are cosmetically broken if at all, and the fixes for them are
usually uglier than the problem.

. The different path settings based on how the shell is started are
normal/traditional. There certainly is not presently a universal way of
configuring the 

. A lot of the differences for different logins are on purpose.

I'm not sure there are any real bugs here. Can you explain what is broken (not
functioning as specified) as opposed to just something you didn't expect?

Comment 11 Jay Turner 2003-04-14 18:58:54 UTC
Closing out due to bit-rot.

Note You need to log in before you can comment on or make changes to this bug.