在调用目录上的chmod()
之前,如果调用者不拥有目录,我想测试调用者是否具有CAP_FOWNER
的能力。在C中测试linux的CAP_FOWNER能力?
从搜索,似乎我应该可以通过调用capable(CAP_FOWNER)
以测试CAP_FOWNER
能力 - 但capable()
是不是我的男人页面之间似乎并没有被<linux/capability.h>
出口。
什么是capable()
的正确包含文件,或者,测试linux功能的最简单/最好的方法是什么?
在调用目录上的chmod()
之前,如果调用者不拥有目录,我想测试调用者是否具有CAP_FOWNER
的能力。在C中测试linux的CAP_FOWNER能力?
从搜索,似乎我应该可以通过调用capable(CAP_FOWNER)
以测试CAP_FOWNER
能力 - 但capable()
是不是我的男人页面之间似乎并没有被<linux/capability.h>
出口。
什么是capable()
的正确包含文件,或者,测试linux功能的最简单/最好的方法是什么?
我认为capable()
在内核源代码中可用,但不能用于一般用途。如果您正在编写设备驱动程序或模块,那么它应该可用。
如果您正在编写用户空间程序,那么您可能可以使用由libcap
提供的函数;见man capabilites
和man libcap
。我建议#include <sys/capability.h>
和使用cap_get_proc()
和可能CAP_IS_SUPPORTED(CAP_FOWNER)
。
如果这样做不好,显而易见的解决方法是尝试chmod()
目录和处理可能的失败。
在调用目录上的chmod()之前,我想测试调用者是否具有CAP_FOWNER能力。
你有理由在应用程序方面做到这一点吗?如果进程调用chmod()
(或任何其他系统调用),内核将在任何情况下检查是否允许进程执行该操作,如果不是,则返回EPERM
或EACCES
。在应用程序端检测这是一个非常简单的测试,并且应用程序在任何情况下都需要进行测试,因为应用程序可能不知道内核完成的所有访问控制。 (比如想想SELinux)
一般来说,测试第一听起来很像Time of check to time of use问题。对于非特权进程,这不是问题,但是如果你的进程代表另一个用户做了一些工作(进程的实际特权高于它想授予用户的权限),它很快就会变成一个。
有帮助,但我仍然想回答我实际询问的问题。 – Conquistadog
这让我走上了正轨。解决方案归结为这些调用: 'cap_t cap = cap_get_proc(); cap_flag_value_t v = 0; cap_get_flag(cap,CAP_FOWNER,CAP_EFFECTIVE,&v);' – Conquistadog