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

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/

Relevant Pages