lkml.org 
[lkml]   [2008]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] exporting capability code/name pairs (try #3)
Quoting Kohei KaiGai (kaigai@ak.jp.nec.com):
> Serge E. Hallyn wrote:
>> Quoting Kohei KaiGai (kaigai@ak.jp.nec.com):
>>>>> All that being said, the friendliness factor of this is somewhat
>>>>> undeniable, and so I can see why folk might want it in the kernel
>>>>> anyway. If so, would it possible to move this code into
>>>>> security/capability.c and not in the main kernel per-se - protected
>>>>> with
>>>>> a configuration option? If it does appear in the kernel, we'll
>>>>> obviously
>>>>> add your libcap changes too. If it doesn't, then perhaps we can meet
>>>>> your needs with a slight modification to your libcap patch to read the
>>>>> capabilities from an optional /etc/XXX file - and make text visibility
>>>>> of 'late breaking' capabilities something that the admin can tweak as
>>>>> needed?
>>>> I think optional configuration file is not a good idea.
>>>> It can make unneeded confusion.
>>>>
>>>> If necessary, I'll move this features into security/capability.c and
>>>> add a Kconfig option to select it.
>>> The following patch enables to export the list of capabilities supported
>>> on the running kernel, under /sys/kernel/capability .
>>>
>>> Changelog from the previous version:
>>> - Implementation is moved into security/capability.c from
>>> kernel/capability.c
>>> - A Kconfig option SECURITY_CAPABILITIES_EXPORT is added to tuen on/off
>>> this feature.
>> can you explain one more time exactly what this lets you do that you
>> absolutely can't do with the current api?
>
> Please consider the following situation:
>
> A user intend to run an application which use a new capability supported
> at new kernel without synced libcap. In this case, the application cannot
> work well, because libcap prevent to use new capability.

(Though we don't want to encourage application writers to not use
libcap...)

> When the kernel and libcap are not synced, the header files provided by
> libcap pacakge is not reliable. Typically, kernel developer sometimes
> faces such a situation. :)

Yeah it would definately be nice for me.

> This feature can fill the gap with providing a new interface to collect
> capabilities supported by the running kernel collectly.
>
>> I for one don't really object even if it is "duplicated" since it is far
>> easier to use, and I frequently have systems where kernel and userspace
>> are out of sync so /usr/include/sys/capabilities is worthless... Though
>> I'm a little worried that b/scripts/mkcapnames.sh is the kind of thing
>> that'll eventually break, but I suppose that's my fault for objecting
>> two duplicated list of capability definitions :)
>
> Are you worried about "mkcapnames.sh" get broken in the future version?
>
> If so, we can add a code to check whether this script works correctly, or
> not
>
> like:
> -- at security/capability.c
> #include <linux/capability.h>
> :
> #if CAP_LAST_CAP != ARRAY_SIZE(capability_attrs)
> #error "mkcapnames.sh added fewer or more entries than expected!"
> #endif

Yeah, the regexp misfiring was my biggest concern so this should help.

thanks,
-serge


\
 
 \ /
  Last update: 2008-02-06 06:11    [W:0.238 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site