Messages in this thread | | | Date | Tue, 5 Feb 2008 23:08:05 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [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
| |