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

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

Chris Wright wrote:
> * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
>> Chris, what is the status of the patch?
> 
> I still don't understand how ...

Hmm...

>>> 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.
> 
> ...libcap can do anything meaningful here with capabilities it doesn't
> know about?  This interface is already versioned, what is wrong is old
> cap version on new kernel (clearly new cap version on old kernel would
> have to fall back to older cap version)?

The versioning info is just a hint in this case.

The major purpose of this patch is to save steps of maintainance.
When we tries to run a application using a new capability provided by
the latest kernel, we have to rebuild libcap to follow kernel updates.

If we can obtain an information what capabilities are supported in
the running kernel, we don't need to rebuild libcap for the latest
kernel everytime.

For example, we got CAP_MAC_ADMIN at 2.6.25. If an application tries to
use it, we have to replace libcap for 2.6.24 by libcap for 2.6.25.
Although, we don't get any updates in libcap. :-(

In addition, I noticed it will be usefull for applications which have
a possibility to use arbitary number of capabilities, like busybox
if setcap/getcap stuff is ported.
(IMO, we should not use libcap for busybox, because its first priority
  is to reduce binary size, limited to minimun functionalities.)

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>