Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

From: KaiGai Kohei
Date: Tue May 13 2008 - 20:45:36 EST


Chris, what is the status of the patch?

KaiGai Kohei wrote:
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,

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/