Chris Wright wrote:* KaiGai Kohei (kaigai@xxxxxxxxxxxxx) wrote:[PATCH 2/3] exporting capability name/code pairs
This patch enables to export code/name pairs of capabilities the running
kernel supported.
A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
at 2.6.25. However, we have no interface to disclose what capabilities
are supported on the running kernel. Thus, we have to maintain libcap
version in appropriate one synchronously.
This patch enables libcap to collect the list of capabilities at run time,
and provide them for users. It helps to improve portability of library.
It exports these information as regular files under /sys/kernel/capability.
The numeric node exports its name, the symbolic node exports its code.
I do not understand why this is necessary. The capability bits are an ABI
that shouldn't change in a non-backward compat way (i.e. only additions).
We typically don't export strings <-> number conversions for constants.
I know you've explained this a few times before, but it still seems to me
like a userspace only problem. What can userspace do with a capability
it does not know about?
When we run a userspace utility on the latest kernel, it has to be compiled
with kernel-headers which have same capability set at least.
If installed userspace utility does not support newly added capabilities,
it requires users to rebuild their utilities when they update the kernel.
Typically, kernel developer faces this kind of version mismatching.
When they boots their kernel with new capabilities, it also requires to
rebuild libcap. Then, they have to revert it, when they boots with normal
kernel.
If libcap can know what capabilities are supported on the running kernel
automatically, it does not need users to rebuild libcap concurrently.
Thanks,