出于某种我不太明白的原因，每个人都希望对一切事物都使用 sudo。在工作中，我们甚至拥有与读取日志文件的方式一样多的条目（head/tail/cat/more，...）。
我认为，sudo 在这里失败了。
我宁愿混合使用 setgid/setuid 目录并在这里和那里添加 ACL，但我确实需要在启动之前知道最佳做法是什么。
我们的服务器有 %admin、%production、%dba、%users - 即许多组和许多用户。每个服务（mysql、apache 等）都有自己的安装权限的方式，但 %production 组的成员必须能够查阅配置文件甚至日志文件。还有一个解决方案是将它们添加到正确的组（mysql 等）并设置良好的权限。但我不想对所有用户进行 usermod，我不想修改标准权限，因为它可能会在每次升级后发生变化。
另一方面，我可以轻松地在目录上设置 acl 和/或混合 setuid/setgid，而无需“破坏”标准分布。
你怎么看待这件事 ？
以 mysql 为例，它看起来像这样：
setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql
您认为这是好的做法吗？或者我应该明确地使用 usermod -G mysql 并使用标准权限系统？
谢谢
答案1
最佳实践：维护 sudoers 文件并使用 sudo。
在我的个人机器上，我更喜欢 setuid/gid，但我的电脑上只有我一个；而且我不会对任何明显危险的事情这样做rm。
答案2
最佳实践（也是最常见的）倾向于使用sudo。Sudo 为您提供细粒度的控制，并且配置可以同时处理多台机器。
使用 ACL 可以补充这一点 -sudo以 root 身份处理操作；ACL 向用户和组授予和剥夺目录和文件的权限。我不会指望 setgid 和 setuid 做任何合理的事。
我还将实现 wheel 组；这将有助于提高安全性。检查您的su程序是否支持 wheel 组。
还有一件事：如果您有view或less作为一种读取日志文件的方法，那么您将面临风险：这两个程序都提供 shell 访问权限。
答案3
在我看来，sudoers 选项比 setuid/setguid/ACL 更紧凑一些。
如果不分组用户，您的 ACLS 将会非常冗长。如果您对用户进行分组，您又会回到开始的地方。
更大的问题是，如果没有某种集中管理，访问控制就会遍布整个文件系统。当然，你可以通过宏、模板、配置管理等轻松解决这个问题。但那是另一个完全不同的层面，对降低复杂性毫无作用。
在我的小型 Drupal 商店中，我广泛使用 ACL 来访问所有工作文件，但使用 sudo 来访问所有管理访问。我使用的配置管理层是 Ansible，它的优点在于我可以轻松模板化用户、他们的角色，以及他们所属的组、在哪些机器上，等等。Sudoers 的管理方式类似。这对我来说似乎是最佳做法，因为它最透明。
当然，我可能没有你那么多用户或组。我也可以设想将 ACL 放入配置管理中。但就我而言，我看不出有什么简单的方法可以以这种方式管理许多机器、许多用户和许多组。