Is there a good reason not to add sbin to the default PATH?

Background:

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.

Solution 1:

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.)

Solution 2:

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.