Bug 15881
Summary: | strange PATH settings | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Michael Redinger <michael.redinger> |
Component: | util-linux | Assignee: | Elliot Lee <sopwith> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-04-14 18:58:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michael Redinger
2000-08-09 18:31:10 UTC
The initial paths are set by login (util-linux) 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 .. :) ). Same in RC1, changing version. There's a bug that's possibly related to this - see bug #16004 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. 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: /usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin:/usr/X11R6/bin:\ /home/c102mr/bin:/usr/X11R6/bin:/usr/X11R6/bin:/home/c102mr/bin xterm: /usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin:/usr/X11R6/bin:\ /home/c102mr/bin:/usr/X11R6/bin xterm -e su -: /usr/local/sbin:/usr/sbin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:\ /usr/local/bin:/usr/local/sbin:/usr/bin/X11:/usr/X11R6/bin:/root/bin xterm -e su: /usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin:/usr/X11R6/bin:\ /home/c102mr/bin:/usr/X11R6/bin xterm -e su -, then su - to normal user: /bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/X11R6/bin:/home/c102mr/bin telnet: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/c102mr/bin 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 -PATH="$PATH:/usr/X11R6/bin" +if echo $PATH | grep -vq /usr/X11R6/bin +then + PATH="$PATH:/usr/X11R6/bin" +fi ulimit -S -c 1000000 > /dev/null 2>&1 if [ `id -gn` = `id -un` -a `id -u` -gt 14 ]; then 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. 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: /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/c102mr/bin (looks good!) xterm -ls as normal user in KDE: /usr/kerberos/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/home/user/bin:/ho me/user/bin (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:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/ sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin (/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: /usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/bin:/sbin: /usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin/X11:/usr/X11R6/bin:/r oot/bin (quite different, right? This is _really_ broken) (please note /usr/bin/X11:/usr/X11R6/bin) ----- login as normal user, then su to root: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin :/home/c102mr/bin xterm -ls in kde, then su to root: /usr/kerberos/sbin:/usr/kerberos/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin :/home/user/bin:/home/user/bin (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: /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/user/bin (this one's fine ...) rsh localhost as normal user, then su to root: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin :/home/user/bin (similar to "su to root", but much better ...) ----- rsh localhost as root: /usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/ sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin (again - some sbin directories are listed twice.) ----- 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: ;) console: user: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/c102mr/bin root: /usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin kde: user: /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/home/c102mr/bin:/home/c102mr/bin root: /usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/root/bin gnome: user: /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/home/c102mr/bin root: /usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/root/bin ssh: user: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/c102mr/bin root: /usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin rlogin: user: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/c102mr/bin root: /usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin rsh (rsh host 'echo $PATH'): user: /usr/bin:/bin root: /usr/bin:/bin . 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? Closing out due to bit-rot. |