是否有一个很好的理由不将sbin添加到默认的PATH？

背景：

PATH环境variables指定在发出命令而不指定path时要search的目录。 “sbin”path（ /sbin ， /usr/sbin ）用于存放pipe理实用程序，因此很多* nix发行版不包含PATH默认设置中的这些目录。也就是说，在很多情况下，非pipe理帐户都需要访问这些实用程序，并且必须指定完整path或修改其PATHvariables才能这样做。这个任务相对容易执行，但对新用户来说可能很麻烦。更糟糕的是，当涉及PAM，sudo，ssh和其他与PATH设置交互并且有时修改PATH设置的实用程序时，会遇到更多的难题。对这个网站或互联网的大量search产生了许多这些问题的例子，这些问题折磨着新老用户。

问题：

有了前面提到的背景，是不是有一个很好的理由不把sbin目录添加到默认的PATH中？（大概是通过/etc/profile ， /etc/profile /etc/profile.d或者等价的）

我认识到“好”是主观的，但是这里有一些我认为不成立的理由。也许你不同意？

不好理由：

安全
- 提升特权和持有实用工具的目录与全球可访问的目录（ rx ）无关。可能会提出一个模糊不清的论点，认为充分无技能的坏人找不到“隐藏的”工具，但这将是一个令人遗憾的透明的幕布。
命名空间
- 有人可能会争辩说，用户可能希望编写自己的reboot命令，通过他们自己的自定义目录访问他们自己的自定义目录，并将其添加到他们的PATH ，并且在sbin目录中的系统默认值将胜过他们的configuration。这是一个angular落的情况，以及有问题的用户已经注意到了PATH含义，并且可以修改他们的configuration以使用序列中的前一个目录。
标准
- 这绝不是对文件系统层次结构标准的改变; 实用程序仍按其function组织到其目录中。
- 没有解决问题，因为“我们习惯了这个问题”是愚蠢的。

常规用户没有真正的理由不在PATH包含这些程序，如果有一个普通用户调用这些程序之一是一个问题，那么程序和/或其安全性需要修复。

在RHEL 6及更高版本中，您会很高兴地发现/sbin和/usr/sbin现在已经成为所有用户的默认PATH ，就像Fedora多年以来一样。（和/sbin是从RHEL 7开始的/usr/sbin的符号链接，但这是另一个问题。）

您可以通过本地或系统范围的PATH定义轻松添加。分离的原因大部分是传统的，并且是“sbin”是系统二进制文件中的命令的function。

在我的安装和环境中，这不是一个问题。我的用户不需要访问系统实用程序。运行sudo或su -的额外步骤su -提升权限或input完整的命令path是合理的，因为系统通常不会托pipe交互式会话。但是，情况可能并非如此。如果这是一个问题，请修改PATHvariables。