试图理解为什么 ssh-agent 有 sgid 位并发现了这篇文章ssh-agent 有 sgid
我还有一个问题，为什么ssh-agent的组所有权是nobody而不是root？其背后的原因是什么？如果组所有权是root，它仍然有效吗？
答案1
如果它是 setgid root 那么代理将以 group 身份运行root，该组可能比它启动时的用户拥有更广泛的权限。这可能存在安全风险；至少，不必要地以 root 身份运行某些东西是一个危险信号（甚至是团体）并且需要额外的关注。
将组所有权设置为nobody，该组不应具有任何有意义的权限或附加文件，这意味着ssh-agent没有获得比用户开始时更多的权限。正如链接的问题所说，它的 setgid 首先是为了防止跟踪程序，而不是因为它实际上需要不同的权限。在里面从其他问题链接的讨论线程，一位开发人员指出：
看来这个团体没有什么影响。事实上，二进制文件是 setgid anygroup ，这一点很重要。
nobody当您只想要 setgid 的副作用而不是行为本身时，可以使用这个方便的组。
我想它仍然可以与 setgid root 一起使用。我刚刚在这里尝试过，它根本没有抱怨，并且在粗略测试中似乎可以工作。也就是说，我想不出任何实际的理由将其更改为该形式 - 每个人似乎都以 group 形式运行比nobodygroup更好root。
无论如何，我不建议更改包管理器安装的文件的权限，因为他们往往会对对其控制的文件进行任何修改感到不安。
答案2
设置 setgid 的目的ssh-agent是通过使进程无法调试来提高安全性，这样即使以同一用户身份运行的进程也无法从内存中转储密钥。
ssh-agent事实上不应该有额外的特权。如果 中存在漏洞ssh-agent，如果将其设置为某个组，则会授予用户该组的权限。因此，运行ssh-agentsetgid 会增加安全风险……除非运行的组ssh-agent实际上没有任何特权 - 特别是没有对任何文件的写入权限。
运行程序 setgid 而不影响其他程序的最佳方法是使用专用组。这就是 Debian 所做的，例如：ssh-agent作为组运行ssh。 Fedora 使用组nobody，虽然比较危险，但仍然可以，因为任何文件都不应该属于该组nobody。该组root将是一个坏主意，因为它拥有大量文件。