lkml.org 
[lkml]   [2008]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)
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>


\
 
 \ /
  Last update: 2008-05-14 08:03    [W:0.073 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site