linux Capability.h 如何对 34 个元素使用 32 位掩码?

发布于 2024-12-23 02:32:25 字数 525 浏览 3 评论 0原文

/usr/include/linux/capability.h 中的文件#定义了 34 种可能的功能。 它是这样的:

#define CAP_CHOWN            0

#define CAP_DAC_OVERRIDE     1

.....

#define CAP_MAC_ADMIN        33

#define CAP_LAST_CAP         CAP_MAC_ADMIN

每个进程都有这样定义的功能

typedef struct __user_cap_data_struct {

        __u32 effective;
        __u32 permitted;
        __u32 inheritable;
} * cap_user_data_t;

我很困惑 - 一个进程可以有 32 位的有效功能,但在 Capability.h 中定义的功能总数是 34。如何在一个进程中编码 34 个位置32 位掩码?

The file in /usr/include/linux/capability.h #defines 34 possible capabilities.
It goes like:

#define CAP_CHOWN            0

#define CAP_DAC_OVERRIDE     1

.....

#define CAP_MAC_ADMIN        33

#define CAP_LAST_CAP         CAP_MAC_ADMIN

each process has capabilities defined thusly

typedef struct __user_cap_data_struct {

        __u32 effective;
        __u32 permitted;
        __u32 inheritable;
} * cap_user_data_t;

I'm confused - a process can have 32-bits of effective capabilities, yet the total amount of capabilities defined in capability.h is 34. How is it possible to encode 34 positions in a 32-bit mask?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

流年已逝 2024-12-30 02:32:25

因为你还没有读完说明书。

capget 手册首先说服您不要使用它:

These two functions are the raw kernel interface for getting  and  set‐
ting  thread capabilities.  Not only are these system calls specific to
Linux, but the kernel API is likely to change and use  of  these  func‐
tions  (in  particular the format of the cap_user_*_t types) is subject
to extension with each kernel revision,  but  old  programs  will  keep
working.

The  portable  interfaces  are  cap_set_proc(3) and cap_get_proc(3); if
possible you should use those interfaces in applications.  If you  wish
to use the Linux extensions in applications, you should use the easier-
to-use interfaces capsetp(3) and capgetp(3).

当前详细信息

Now that you have been warned, some current kernel details.  The struc‐
tures are defined as follows.

#define _LINUX_CAPABILITY_VERSION_1  0x19980330
#define _LINUX_CAPABILITY_U32S_1     1

#define _LINUX_CAPABILITY_VERSION_2  0x20071026
#define _LINUX_CAPABILITY_U32S_2     2

[...]
effective,  permitted,  inheritable  are  bitmasks  of the capabilities
defined in capability(7).  Note the CAP_* values are  bit  indexes  and
need to be bit-shifted before ORing into the bit fields.
[...]
Kernels  prior  to  2.6.25  prefer  32-bit  capabilities  with  version
_LINUX_CAPABILITY_VERSION_1, and kernels 2.6.25+ prefer 64-bit capabil‐
ities with version _LINUX_CAPABILITY_VERSION_2.  Note, 64-bit capabili‐
ties  use  datap[0]  and datap[1], whereas 32-bit capabilities only use
datap[0].

,其中 datap 之前被定义为指向 __user_cap_data_struct 的指针。因此,您只需在两个 __user_cap_data_struct 数组中用两个 __u32 表示 64 位值。

仅这一点就告诉我永远不要使用这个 API,所以我没有阅读手册的其余部分。

Because you haven't read all of the manual.

The capget manual starts by convincing you to not use it :

These two functions are the raw kernel interface for getting  and  set‐
ting  thread capabilities.  Not only are these system calls specific to
Linux, but the kernel API is likely to change and use  of  these  func‐
tions  (in  particular the format of the cap_user_*_t types) is subject
to extension with each kernel revision,  but  old  programs  will  keep
working.

The  portable  interfaces  are  cap_set_proc(3) and cap_get_proc(3); if
possible you should use those interfaces in applications.  If you  wish
to use the Linux extensions in applications, you should use the easier-
to-use interfaces capsetp(3) and capgetp(3).

Current details

Now that you have been warned, some current kernel details.  The struc‐
tures are defined as follows.

#define _LINUX_CAPABILITY_VERSION_1  0x19980330
#define _LINUX_CAPABILITY_U32S_1     1

#define _LINUX_CAPABILITY_VERSION_2  0x20071026
#define _LINUX_CAPABILITY_U32S_2     2

[...]
effective,  permitted,  inheritable  are  bitmasks  of the capabilities
defined in capability(7).  Note the CAP_* values are  bit  indexes  and
need to be bit-shifted before ORing into the bit fields.
[...]
Kernels  prior  to  2.6.25  prefer  32-bit  capabilities  with  version
_LINUX_CAPABILITY_VERSION_1, and kernels 2.6.25+ prefer 64-bit capabil‐
ities with version _LINUX_CAPABILITY_VERSION_2.  Note, 64-bit capabili‐
ties  use  datap[0]  and datap[1], whereas 32-bit capabilities only use
datap[0].

where datap is defined earlier as a pointer to a __user_cap_data_struct. So you just represent a 64bit values with two __u32 in an array of two __user_cap_data_struct.

This, alone, tells me to not ever use this API, so i didn't read the rest of the manual.

燃情 2024-12-30 02:32:25

它们不是位掩码,它们只是常量。 EG CAP_MAC_ADMIN 设置多个位。在二进制中,33 是什么,10001?

They aren't bit-masks, they're just constants. E.G. CAP_MAC_ADMIN sets more than one bit. In binary, 33 is what, 10001?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文