Description of problem: When a non-root user wants to use a command like "ifconfig", he has to type /sbin/ifconfig because this program is not in his path. When you get root permissions with su or sudo, you have the same problem. For example, "sudo service foo start" does not work because "service" is in /sbin. Version-Release number of selected component (if applicable): Actually, all Red Hat and Fedora versions I know have this problem. My proposal is to add /usr/local/sbin, /usr/sbin and /sbin BEHIND the existing path in the /etc/profile script. See attached patch on how to do this. It does not interfere with tools like consolehelper because the "sbin"'s are added at the end of $PATH.
Created attachment 259831 [details] Patch to add "sbin" paths behind $PATH for non-root users
If you ask me, that's not a bug, it's desired behaviour. If a non-root user wants to use sbin commands they can freely type /sbin/ifconfig. /sbin contains tools that are generally only of use the system administrators. Long may this continue.
I strongly support this Enhancement Request. There are frequently reasons for non-root users to want to run tools in /sbin and /usr/sbin. I can't see any strong reason to exclude those directories from the PATH -- there is no security issue here. There is however a significant usability issue -- it confuses users who come from other Linux distributions where /sbin and /usr/sbin are in the PATH for all users. It also makes using sudo, etc., friendlier.
This has been discussed numerous times on Fedora and other mailinglists, and there are 2 camps with one preferring it to be included while the other says it's a security risk. As i'm more inclined to agree with the 2nd group i'm afraid i unfortunately have to turn down your request here. Read ya, Phil
Can't it be included as an easy configurable option? That would be a reasonable trade-off between security concerns (???) and functionality.
It is easily configurable already, a single line change in the profile scripts. I'd still argue that this has nothing to do with security, and everything to do with usability. It's better to default to sbin not being in a typical user's path. If the admin knows better, then the admin can change the profile. If the admin doesn't know how to, then the admin doesn't know better. If it's a single user who knows better, then the single user can change their profile. If they don't know how to, they don't know better. jh