我正在努力限制现有的复杂应用程序的功能，我一直在寻找一个可靠的来源，证明cap_dac_override中包含的权限是cap_dac_read_search的超集。
根据capabilities(7)，确实如此合乎逻辑：
CAP_DAC_OVERRIDE *绕过文件读取，写入和执行权限检查。
CAP_DAC_READ_SEARCH *绕过文件读取权限检查和目录读取和执行权限检查; *调用open_by_handle_at（2）; *使用linkat（2）AT_EMPTY_PATH标志创建指向文件描述符引用的文件的链接。
此外，我的能力检查示踪剂的实验证实，cap_dac_override应该足够了。 cap_dac_read_search似乎在每次执行读取访问时都会在cap_dac_override之前进行检查。
我还发现了关于grsecurity forums的以下帖子，其中不幸的是只关注/proc：
上游内核的工作方式是首先检查CAP_DAC_OVERRIDE，然后检查CAP_DAC_READ_SEARCH。
如果我想给我的应用程序授予对整个文件系统的完全读取权限，我仍然不确定是否完全可以省略cap_dac_read_search。我完全清楚cap_dac_override还会授予写入权限，我希望如此。
是否有可能在内核中有一个地方只有cap_dac_read_search的检查而不是cap_dac_override？
我是否应该将这些功能包含在安全的一面，还是cap_dac_read_search在这种情况下完全冗余？
经过一些额外的验证和实际测试后，似乎cap_dac_override确实是cap_dac_read_search的超集。
当cap_dac_read_search从相关应用程序中删除时，由于权限被拒绝，没有一个操作失败。