如何执行进程，尽pipe缺less基于文件系统的function，仍然保留了function？

我并不是说我推荐你这样做，但是在这里。

从手册中提取出来，有一些变化。 据此： fork不改变能力。 现在在Linux内核4.3中增加了一个环境集 ，看起来这是你正在做的事情。

  Ambient (since Linux 4.3): This is a set of capabilities that are preserved across an execve(2) of a program that is not privileged. The ambient capability set obeys the invariant that no capability can ever be ambient if it is not both permitted and inheritable. The ambient capability set can be directly modified using prctl(2). Ambient capabilities are automatically lowered if either of the corresponding permitted or inheritable capabilities is lowered. Executing a program that changes UID or GID due to the set- user-ID or set-group-ID bits or executing a program that has any file capabilities set will clear the ambient set. Ambient capabilities are added to the permitted set and assigned to the effective set when execve(2) is called. A child created via fork(2) inherits copies of its parent's capability sets. See below for a discussion of the treatment of capabilities during execve(2). Transformation of capabilities during execve() During an execve(2), the kernel calculates the new capabilities of the process using the following algorithm: P'(ambient) = (file is privileged) ? 0 : P(ambient) P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset) | P'(ambient) P'(effective) = F(effective) ? P'(permitted) : P'(ambient) P'(inheritable) = P(inheritable) [ie, unchanged] where: P denotes the value of a thread capability set before the execve(2) P' denotes the value of a thread capability set after the execve(2) F denotes a file capability set cap_bset is the value of the capability bounding set (described below). A privileged file is one that has capabilities or has the set-user-ID or set-group-ID bit set. 

目前还没有简单的方法来做到这一点，如果你参考了能力的手册页：

 During an execve(2), the kernel calculates the new capabilities of the process using the following algorithm: P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset) P'(effective) = F(effective) ? P'(permitted) : 0 P'(inheritable) = P(inheritable) [ie, unchanged] where: P denotes the value of a thread capability set before the execve(2) P' denotes the value of a capability set after the execve(2) F denotes a file capability set cap_bset is the value of the capability bounding set 

如果要执行的文件没有设置其fP位，或者未设置fI位，则您的进程将不允许进行，因此也没有有效的功能。

设置允许的整个文件系统和继承位在技术上是可行的，但是这样做没有什么意义，因为它会大大降低系统的安全性（编辑：正如你所提到的，这对于新的可执行文件来说不起作用）。

你确实可以通过pam_cap给用户一些功能，但是你不能让他们执行任何他们刚刚编译的文件。 功能是为了给程序而不是给用户设计的，你可以阅读Hallyn的论文 ：

一个关键的洞察是观察到程序而不是人们行使特权。 也就是说，在电脑上完成的所有事情都是通过代理程序进行的，只有当这些程序知道如何处理特权时，才可以信任它们。

另请参阅定义POSIX功能的POSIX草案 1003.1e，第310页：

建立一个过程链（一个过程中的一系列程序）也是不恰当的，这个过程链在整个生命周期中都保持固定和活跃。 […]这是最小权限原则的应用，它同样适用于用户和进程。

有人要求在最近的这个 Linux内核邮件列表中介绍你想做的功能，并给出了一些非常有意思的答案。 有些人认为，通过exec删除文件功能的继承规则会引入一些安全问题，并且这些功能并不是针对这样的功能而设计的，尽管没有给出关于哪个安全问题的解释：

目前唯一的方法是修改Linux内核中的能力继承方式（2个文件需要修改，我已经在3.7内核上成功测试过了），但是不清楚上面提到的是否安全。

在旧内核（在2.6.33之前）有一个选项来编译没有文件的能力（ CONFIG_SECURITY_FILE_CAPABILITIES ），但我怀疑这样一个旧的内核是一个选项。

我认为（我的理解），使用功能的最佳方式是：

• 对于需要功能且值得信任的程序，包括可信的不泄漏功能的程序：例如数据包嗅探的一部分，一个需要在端口80上侦听的web服务器。
  • 新程序，功能感知：设置允许。
  • 遗留程序，而不是功能意识：设置允许和有效
• 对于将泄漏功能的程序，以及具有（有时）使用能力的代码：set inherited
  • 例如chmod set继承CAP_FOWNER，如果用户需要超级权力（通常由root用户拥有的权力），那么他们需要使用setpriv （或等效的，这可以被卷成sudo ），否则它在非特权模式下工作。
• 当一个进程需要分叉和共享一些功能，然后才使用环境。 可能是相同的可执行文件; 如果它是一个不同的，那么这个新的将允许或继承的文件集。 [编辑：我刚刚意识到，你不需要环境，如果你不执行。 如果我想到一个用于环境的用例，在一个设置良好的系统中，我将在这里添加它。 环境可以作为一个过渡机制，当继承没有设置的文件可以使用它。]

环境的使用：

• 在文件不具有正确功能的系统上。 （过渡技术）。
• 对于shell脚本，不能有能力（因为他们不能有setuid），除非在已经修复的系统上，然后在脚本上允许setuid。
• 在这里添加更多。