lkml.org 
[lkml]   [2008]   [Feb]   [6]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
DateTue, 5 Feb 2008 23:08:05 -0600
From"Serge E. Hallyn" <>
SubjectRe: [PATCH 1/3] exporting capability code/name pairs (try #3)
Digg This
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



\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2008-02-06 05:11    [W:0.688 / U:0.010 seconds]
©2003-2005 Jasper Spaans