无法获得新的服务来尊重能力(7)

Question

我正在开发一个由upstart (Ubuntu14.04)启动的守护进程，它需要以非特权用户的身份运行(为了安全起见)，但是绑定特权端口443。

我使用setcap来设置可执行文件的CAP_NET_BIND_SERVICE功能(它不是脚本)。我将其设置为允许的、有效的和继承的集合(setcap 'cap_net_bind_service+eip' EXEC)。

我可以su给非特权用户，并直接运行它，它工作得很好.它正确地绑定了端口，/proc/PID/status显示了适当的功能掩码，设置了0x400位。

但是，当我通过upstart启动服务时，它不会使用为二进制文件指定的功能运行，并且bind()失败(EPERM)。/proc/PID/status显示功能掩码全部为0。

有什么想法吗？

Answer 1

我现在认为这是一个bug，它与upstart使用"expect守护进程“(即在启动时分叉两次的服务)启动服务的方式有关。我注意到，如果我在使用功能(7)的进程上使用strace，那么这些功能也会被忽略。我怀疑upstart为了确定等待的PID，跟踪使用"expect daemon“指定的服务足够长以获得PID，这将导致内核功能机制失败。因此，错误在于功能与进程跟踪交互的方式，以及upstart在使用"expect daemon“启动服务时使用流程跟踪的事实(这是假设)。

作为一个简单的测试：

1. 编写一个小的C程序来绑定到端口443 (您不能使用像python这样的具有功能(7)的解释语言)。
2. 以非根用户的身份运行它，并看到它由于缺乏特权而无法绑定。
3. 为您的程序设置CAP_NET_BIND_SERVICE功能(作为根运行setcap 'cap_net_bind_service+epi' PROGRAM)
4. 以非根的形式运行它，并确保它现在成功。
5. 现在用strace运行它，看看它现在失败了。

(请注意，严格地说，在步骤3中，这个测试不需要修改继承的功能集(i标志)，但是对于一个forks()进程，比如我的守护进程，它需要修改)。

关于这一点，我将针对内核提交一个bug，因为功能(7)手册页面上没有任何东西说它不应该与进程跟踪一起工作。

Answer 2

解决方法之一是不使用expect叉或expect守护进程，只需将守护进程作为前台进程即可。那么Upstart根本就不会跟踪它。