Why not caps?

TL;DR: In the opinion of capctl's author, caps adds too much abstraction and overhead.

1. The kernel APIs to access the 5 capability sets (permitted, effective, inheritable, bounding, and ambient) are very different. However, caps presents a unified interface that allows for manipulating all of them the same way.

   这无疑更方便使用。然而，a) 它最小化了能力集之间的差异（这是基本且必须理解的，以便正确使用能力），b) 它允许用户编写尝试执行实际上不可能的操作的代码（例如，将能力添加到边界能力集中），以及 c) 它可能导致过多的系统调用（因为内核API允许一起执行的操作必须单独执行）。

   注意：如果同时提供底层API以允许用户进行更细粒度的控制，则《capctl》的作者并不完全反对添加此类接口。然而，《caps》并没有这样做。

2. capctl在内部使用更有效的表示。

   例如，《caps》使用HashSet来存储能力集，这是浪费的。《capctl》同时，有一个定制的CapSet结构体，它以更有效的方式存储一组能力。(CapSet还具有专门设计用于处理能力的函数，而不仅仅是作为通用的集合实现。）

为什么不使用prctl？

TL;DR：《prctl》是一个非常底层的封装crate，其中一些“安全”代码应该是unsafe。

1. 《prctl》专注于prctl()系统调用，而不是Linux能力。因此，其Linux能力的接口是次要的，且不完整。

2. 当发生错误时，《prctl》返回原始的errno值。这个crate返回一个更友好的自定义错误类型，可以转换为io::Error。

3. 最重要的是，《prctl》未能认识到，正如手册页面所解释的，prctl()是一个非常底层的系统调用，应该谨慎使用。

   因此，prctl中的一些“安全”函数实际上非常不安全！prctl::set_mm()是最差的例子：它可以用来设置原始地址，例如堆的末尾（就像使用brk()一样），而且它是一个“安全”函数！它甚至接受这些地址作为libc::c_ulong而不是原始指针，这使得它容易受到滥用。