Revision as of 19:06, 1 August 2008

/sbin sanity

Summary

Fix problems arising from the split between /bin and /sbin.

Owner

WillWoods, JesseKeating, AdamJackson, PeterJones, et. al.

Current status

Targeted release: Fedora 10
Last updated: March 25, 2008
Percentage of completion: 0%

Detailed Description

Historically, Fedora enforces the split between /bin and /sbin by leaving /sbin and /usr/sbin out of the PATH for normal users. However, binaries that are commonly used for information-gathering (ifconfig, route) by normal users should not be placed out of their reach. Things that are commonly run with sudo should also be in PATH.

Therefore, we should either be smarter about where binaries are located or change the default PATH.

Benefit to Fedora

This is possibly the most common Fedora FAQ. It's the first problem that anyone new to Fedora encounters and it causes people annoyance for no real gain.

Scope

Change the default PATH to include /usr/local/sbin:/usr/sbin:/sbin for all users. Note that it must come at the end of the path for normal users, or consolehelper will break.

Packages and files to change

setup
/etc/profile - for bash, zsh, etc.
/etc/csh.login - for csh, tcsh, etc.

Test Plan

Ensure that the system starts as expected, without messages about missing binaries or anything similar.

Try running each command as a normal user.

User Experience

Things like ifconfig and sudo service NetworkManager restart work as expected for normal users.

People are no longer baffled by "missing" binaries after using su.

Dependencies

None.

Contingency Plan

Revert the change to setup and everything goes back to the way it was.

Documentation

None needed

Release Notes

/usr/local/sbin:/usr/sbin:/sbin has been added to the PATH for normal users, to simplify command-line administration tasks.

Comments and Discussion

See Talk:Features/SbinSanity

@@ Line 63: / Line 63: @@
 <code>/usr/local/sbin:/usr/sbin:/sbin</code> has been added to the <code>PATH</code> for normal users, to simplify command-line administration tasks.
-== Comments / Discussion ==
+== Comments and Discussion ==
-Are there any drawbacks to putting <code>/usr/local/sbin:/usr/sbin:/sbin</code> in <code>PATH</code>?
-Some things (<code>/sbin/start_udev</code> is one example) will never be run by normal users and are not used in typical system administration. These things should not be in the PATH for normal users, if it can be avoided.
-Doesn't <code>libexec</code> already exist to contain binaries that are never run by users?
-Technically <code>/usr/libexec</code> is for binaries that are never run by ''humans'' - they're designed to be spawned by other processes. if <code>/libexec</code> existed, that would be a good place for something like <code>start_udev</code>.
-Alternate approach: couldn't we just symlink commonly-used binaries into <code>/bin</code> or <code>/usr/bin</code>?
-Yes, but this requires editing and rebuilding dozens of RPMs and constant argument about which binaries deserve special treatment. Lots more work for very little actual improvement.
-MatthiasClasen: I don't have any strong opinion on this proposal, but I have to wonder what definition of 'normal user' includes 'regularly uses ifconfig and route'...
-In that context, "normal user" meant "non-root user".
+See [[Talk:Features/SbinSanity]]
 ----
 [[Category:FeaturePageIncomplete]]

Search

Features/SbinSanity: Difference between revisions