Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


The PATH environment variable specifies the directories to be searched through when a command is issued without specifying a path. "sbin" paths (/sbin, /usr/sbin) are intended to house administrative utilities, such that many *nix distributions don't include these directories in the default setting for PATH. That said, there are many circumstances where non-administrative accounts legitimately need to access these utilities, and must specify full paths or modify their PATH variable to do so. This task is relatively easy to perform, but can be cumbersome for new users. Worse, there are more difficult problems when you involve PAM, sudo, ssh, and other utilities which interact with and sometimes modify the PATH setting. A search of this site or the internet at large yields many samples of these problems, which afflict new and veteran users alike.

The Question:

With the aforementioned background, is there a good reason not to add sbin directories to the default PATH ? (presumably through /etc/profile ,/etc/profile.d, or equivalent)

I recognize "good" is subjective, but here are some reasons that don't hold water in my opinion. Perhaps you disagree?

Not Good Reasons:

  • Security
    • Elevated privileges and the directory holding a utility are unrelated for world-accessible directories (r-x). An obscurity argument might be made that sufficiently unskilled bad guys couldn't find "hidden" utilities, but this would be a sadly transparent curtain.
  • Namespace
    • One might argue that a user might want to write their own reboot command, which they access through their own custom directory, which they added to their PATH, and a system default in a sbin directory would trump their configuration. This is a corner case, and a case where the user in question already groks PATH implications and can modify their config to use their directory earlier in the sequence.
  • Standards
    • This in no way is a change to the Filesystem Hierarchy Standard; utilities are still organized into their directories according to their function.
    • Not fixing a problem because "we're used to having that problem" is silly.
share|improve this question
up vote 3 down vote accepted

There's no real reason for regular users to not have these programs in their PATH, and if having a regular user call one of these programs is an issue, then the program and/or its security need to be fixed.

You'll be happy to find in RHEL 6 and higher that /sbin and /usr/sbin are now in the default PATH for all users, as it has been in Fedora for many years. (And /sbin is a symlink to /usr/sbin starting from RHEL 7, but that's another issue.)

share|improve this answer

You can add this easily through local or system-wide PATH definition. The reason for the separation is mostly tradition and was a function of commands in "sbin" being system binaries...

In my installations and environments, this is not a problem. My users don't need access to system utilities. The added step of running sudo or su - to escalate privileges or typing a full command path is a reasonable one, as the systems either do not typically host interactive sessions. However, that may not be the case for your situation. If it's a problem, modify the PATH variable.

share|improve this answer
That mailing list thread explains a hell of a lot about Debian. – Michael Hampton Oct 6 '13 at 2:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.