c - setuid 程序的管道访问权限

Question

我正在扩展一些在 GNU/Linux (Ubuntu 14.04) 下运行的软件(我不是作者)，由一个 manager 进程和几个 worker 组成过程。管理器可以通过我可以在配置文件中指定的命令行启动工作器。

启动一个worker后，manager使用管道与它通信。出于安全原因，我们决定让工作人员在与经理不同的用户下运行(让我们称他们为 manager-user 和 worker-user)。这是通过编写一个小的包装器脚本来实现的，该脚本使用 su 切换用户并启动一个新的 worker。在此之后，管理器可以通过管道与工作进程进行通信。这种方法已经奏效了好几个月。

作为 su 的替代方案，我们考虑过使用 setuid 位来运行 worker。所以我们编写了一个 C 包装器，管理器可以调用它来启动一个 worker。如果我们将包装器配置为由 manager-user 拥有，则 worker 会正确启动(但当然会使用错误的权限)。如果我们将包装器配置为由 worker-user 拥有并设置 setuid 位，则工作人员将启动但随后退出，因为他们无法连接到管理器。

所以我的问题是:运行 setuid 可执行文件如何影响父进程和子进程创建的管道的权限？会不会是通过 setuid-wrapper 启动的工作进程没有权限打开管理器的管道(或相反)？如果是这种情况，我们如何更改这些权限？

我对使用 setuid 的经验很少，因此欢迎提供任何信息/解释。

Answer 1

Unix pipe 可以命名或未命名。命名管道作为一个文件实现，它具有标准的用户、组和世界所有权权限位。

未命名的管道也有权限，但这些权限受到管道启动时的 euid、egid 和 umask 的限制已创建。

因此，如果您的 worker-user 是另一个用户的 setuid，具有不同的组权限，除非 egid 与master 进程，它将无法使用用户或组权限访问父进程创建的管道。

当然，对于某些 umask 值，未命名管道世界权限将允许进程通过管道进行通信，但是任何进程都能够读取/写那个管道。未命名比命名管道更安全，但向任何管道授予世界权限并不是一个好的安全做法。

此用例(希望两个通信进程在不同用户下运行)的可能解决方案是同时拥有 manager-user 和 worker-user 进程在同一个组中，并且在创建管道时将 umask 的 group-perm 位清除，以便两个进程都可以读取和写入未命名管道.

如果

1. manager-user 由team 拥有，
2. worker-user 也由 team 拥有，
3. 两个进程都清除了它们的组 umask 位(没有值 1x .. 7x)
4. 在创建无名管道之前

然后 manager-user 应该能够在未命名的管道上写入并且 worker-user 应该能够读取它(或者反之亦然，取决于管道的使用方式)，即使它们作为单独的用户运行也是如此。

有关权限位的详细信息，请参阅 chmod 的 man 页面。