Quoting Kohei KaiGai ([EMAIL PROTECTED]): > Serge E. Hallyn wrote: >> Quoting Kohei KaiGai ([EMAIL PROTECTED]): >>>>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
