Re: [PATCH 1/3] exporting capability code/name pairs (try #3)

[Serge E. Hallyn]

Quoting Kohei KaiGai (kaigai@xxxxxxxxxxxxx):
> Serge E. Hallyn wrote:
>> Quoting Kohei KaiGai (kaigai@xxxxxxxxxxxxx):
>>>>> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/