在Linux系统上,root权限可以比使用文件功能添加setuid位更有选择性地授予。有关详细信息,请参阅capabilities(7)
。这些是文件的属性,可以使用getcap
程序读取。如何在Python中检索这些属性?
即使使用例如subprocess
来运行getcap
程序来回答这样的问题是可能的,但是在检索非常多的能力时是不期望的。
应该可以使用ctypes
设计一个解决方案。有没有替代这种方法的方法,甚至有没有帮助完成这项任务的库?
在Linux系统上,root权限可以比使用文件功能添加setuid位更有选择性地授予。有关详细信息,请参阅capabilities(7)
。这些是文件的属性,可以使用getcap
程序读取。如何在Python中检索这些属性?
即使使用例如subprocess
来运行getcap
程序来回答这样的问题是可能的,但是在检索非常多的能力时是不期望的。
应该可以使用ctypes
设计一个解决方案。有没有替代这种方法的方法,甚至有没有帮助完成这项任务的库?
3条答案
按热度按时间xriantvc1#
Python 3.3附带了
os.getxattr
。如果没有,是的.一种方法是使用ctypes
,至少可以获得原始数据,或者使用pyxattr
对于
pyxattr
:字符串
对于Python 3.3的版本,它本质上是相同的,只是导入
os
,而不是xattr
。现在,我们得到了原始结果,这意味着这两个只在检索文本属性时最有用。但是...我们可以使用与
getcap
相同的方法,通过libcap
本身[警告,这将仅在Python 2上按原样工作,如最初编写的那样-阅读结尾的注解以了解详细信息]:型
这给了我:
型
可能对你更有用
PS:注意,
cap_to_text
返回的是malloc
艾德化的字符串,您需要使用cap_free
进行释放关于“binary gibberish”的提示:
型
在那个
8192
中,唯一有效的位是第13位。如果你转到linux/capability.h
,你会看到CAP_NET_RAW
被定义在13
。现在,如果你想写一个包含所有这些常量的模块,你可以解码这些信息,但我得说这比只使用
ctypes
+libcap
要费力得多。PS2:我注意到另一个回答提到我在
ctype
解决方案上的调用有问题。这是因为我 * 可能 * 在2014年使用Python 2.x编写的(因为Python 3提供了os.getxattr
)。这里的关键是要提醒,在Python 2.x中没有
bytes
对象,str
和unicode
是独立的实体。Python 3.x合并了这两个对象,因此str
现在基本上是unicode
,这可能会扰乱C接口。因此,如果使用Python 3(可能是目前的情况),请确保在将字符串传递给
libcap
之前将其转换为bytes
(例如,foo_bar.encode('utf-8')
),并对结果进行反向操作。sc4hvdpw2#
我尝试了Ricardo Cárdenes的答案中的代码,但它对我来说不能正常工作,因为
ctypes
调用的一些细节不正确。这个问题导致一个截断的路径字符串被传递到libcap
内部的getxattr(...)
,从而为错误的项目返回了错误的功能列表(/
目录,或其他第一个路径字符,而不是实际的路径)。记住并解释Python 3.X中
str
和bytes
之间的差异非常重要。这段代码在Python 3.5/3.6上可以正常工作:字符串
输出将如下所示(任何不存在的东西,或者没有设置功能的东西都将返回
''
:型
vh0rcniy3#
getcap.py
字符串
setcap.py all capabilities =ep)
型
备注: