* [PATCH 0/3] exporting capability name/code pairs (final#2) @ 2008-02-25 6:06 Kohei KaiGai 2008-02-25 6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai ` (3 more replies) 0 siblings, 4 replies; 32+ messages in thread From: Kohei KaiGai @ 2008-02-25 6:06 UTC (permalink / raw) To: greg, morgan, serue; +Cc: linux-security-module, linux-kernel The following three patches enables to export code/name pairs of capabilities the running kernel supports, and add a documentation and samples to use this feature. [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can refer this information to identify what entry is accessed. It makes easier to share a single method implementation with several similar entries, like ones to export the list of capabilities the running kernel supports. [PATCH 2/3] exporting capability name/code pairs This patch enables to export code/name pairs of capabilities the running kernel supported. A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN at 2.6.25. However, we have no interface to disclose what capabilities are supported on the running kernel. Thus, we have to maintain libcap version in appropriate one synchronously. This patch enables libcap to collect the list of capabilities at run time, and provide them for users. It helps to improve portability of library. It exports these information as regular files under /sys/kernel/capability. The numeric node exports its name, the symbolic node exports its code. [PATCH 3/3] a new example to use kobject/kobj_attribute This patch can provide a new exmple to use kobject and attribute. The _show() and _store() method can refer/store the private data field of kobj_attribute structure to know what entries are accessed by users. It will make easier to share a single _show()/_store() method with several entries. o changes from the previous version - add a short description at Documentation/kobject.txt, to use private member within kobj_attribute. - "supported" is replaced with "supports" at sysfs-kernel-capability. - "$(src)/../" is replaced with "$(srctree)/" at security/Makefile - The private member is casted to long, when it stores integer value. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-25 6:06 [PATCH 0/3] exporting capability name/code pairs (final#2) Kohei KaiGai @ 2008-02-25 6:10 ` Kohei KaiGai 2008-02-25 6:51 ` Greg KH 2008-02-28 5:49 ` Valdis.Kletnieks 2008-02-25 6:10 ` [PATCH 2/3] exporting capability name/code pairs (final#2) Kohei KaiGai ` (2 subsequent siblings) 3 siblings, 2 replies; 32+ messages in thread From: Kohei KaiGai @ 2008-02-25 6:10 UTC (permalink / raw) To: greg, morgan, serue; +Cc: Kohei KaiGai, linux-security-module, linux-kernel [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can refer this information to identify what entry is accessed. It makes easier to share a single method implementation with several similar entries, like ones to export the list of capabilities the running kernel supports. Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> -- Documentation/kobject.txt | 6 ++++++ include/linux/kobject.h | 1 + include/linux/sysfs.h | 7 +++++++ 3 files changed, 14 insertions(+), 0 deletions(-) diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt index bf3256e..efa5d71 100644 --- a/Documentation/kobject.txt +++ b/Documentation/kobject.txt @@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created with the kobject_create_and_add(), can be of type kobj_attribute, so no special custom attribute is needed to be created. +The simple kobj_attribute is prototyped at include/linux/kobject.h, and can +contain your own show()/store() method and private data. +When an attribute is accessed, these methods are invoked with kobject, +kobj_attribute and read/write buffer. The method can refer the private data +via given kobj_attribute, to show/store itself in the text representation. + See the example module, samples/kobject/kobject-example.c for an implementation of a simple kobject and attributes. diff --git a/include/linux/kobject.h b/include/linux/kobject.h index caa3f41..57d5bf1 100644 --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -130,6 +130,7 @@ struct kobj_attribute { char *buf); ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count); + void *data; /* a private field */ }; extern struct sysfs_ops kobj_sysfs_ops; diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h index 8027104..6f40ff9 100644 --- a/include/linux/sysfs.h +++ b/include/linux/sysfs.h @@ -50,6 +50,13 @@ struct attribute_group { .store = _store, \ } +#define __ATTR_DATA(_name,_mode,_show,_store,_data) { \ + .attr = {.name = __stringify(_name), .mode = _mode }, \ + .show = _show, \ + .store = _store, \ + .data = (void *)(_data), \ +} + #define __ATTR_RO(_name) { \ .attr = { .name = __stringify(_name), .mode = 0444 }, \ .show = _name##_show, \ -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-25 6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai @ 2008-02-25 6:51 ` Greg KH 2008-02-25 6:57 ` Kohei KaiGai 2008-02-28 5:49 ` Valdis.Kletnieks 1 sibling, 1 reply; 32+ messages in thread From: Greg KH @ 2008-02-25 6:51 UTC (permalink / raw) To: Kohei KaiGai; +Cc: morgan, serue, linux-security-module, linux-kernel On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: > [PATCH 1/3] add a private data field within kobj_attribute structure. > > This patch add a private data field, declared as void *, within kobj_attribute > structure. The _show() and _store() method in the sysfs attribute entries can > refer this information to identify what entry is accessed. > It makes easier to share a single method implementation with several similar > entries, like ones to export the list of capabilities the running kernel > supports. > > Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> > -- > Documentation/kobject.txt | 6 ++++++ That's good, but you didn't modify the sample/kobject/ file to use the new void pointer, instead of the strcmp() call. thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-25 6:51 ` Greg KH @ 2008-02-25 6:57 ` Kohei KaiGai 2008-02-25 7:47 ` Greg KH 0 siblings, 1 reply; 32+ messages in thread From: Kohei KaiGai @ 2008-02-25 6:57 UTC (permalink / raw) To: Greg KH; +Cc: morgan, serue, linux-security-module, linux-kernel Greg KH wrote: > On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: >> [PATCH 1/3] add a private data field within kobj_attribute structure. >> >> This patch add a private data field, declared as void *, within kobj_attribute >> structure. The _show() and _store() method in the sysfs attribute entries can >> refer this information to identify what entry is accessed. >> It makes easier to share a single method implementation with several similar >> entries, like ones to export the list of capabilities the running kernel >> supports. >> >> Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> >> -- >> Documentation/kobject.txt | 6 ++++++ > > That's good, but you didn't modify the sample/kobject/ file to use the > new void pointer, instead of the strcmp() call. The 3/3 of patches updates sample/kobject to use the new void pointer. Do you want it to replace strcmp() examples completly? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-25 6:57 ` Kohei KaiGai @ 2008-02-25 7:47 ` Greg KH 2008-02-25 10:04 ` Kohei KaiGai 0 siblings, 1 reply; 32+ messages in thread From: Greg KH @ 2008-02-25 7:47 UTC (permalink / raw) To: Kohei KaiGai; +Cc: morgan, serue, linux-security-module, linux-kernel On Mon, Feb 25, 2008 at 03:57:44PM +0900, Kohei KaiGai wrote: > Greg KH wrote: >> On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: >>> [PATCH 1/3] add a private data field within kobj_attribute structure. >>> >>> This patch add a private data field, declared as void *, within >>> kobj_attribute >>> structure. The _show() and _store() method in the sysfs attribute entries >>> can >>> refer this information to identify what entry is accessed. >>> It makes easier to share a single method implementation with several >>> similar >>> entries, like ones to export the list of capabilities the running kernel >>> supports. >>> >>> Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> >>> -- >>> Documentation/kobject.txt | 6 ++++++ >> That's good, but you didn't modify the sample/kobject/ file to use the >> new void pointer, instead of the strcmp() call. > > The 3/3 of patches updates sample/kobject to use the new void pointer. > Do you want it to replace strcmp() examples completly? Doh, I totally missed that one, very sorry. I'll be glad to take patches 1 and 3 in my tree, if you want me to. thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-25 7:47 ` Greg KH @ 2008-02-25 10:04 ` Kohei KaiGai 2008-02-26 20:09 ` Greg KH 0 siblings, 1 reply; 32+ messages in thread From: Kohei KaiGai @ 2008-02-25 10:04 UTC (permalink / raw) To: Greg KH; +Cc: morgan, serue, linux-security-module, linux-kernel Greg KH wrote: > On Mon, Feb 25, 2008 at 03:57:44PM +0900, Kohei KaiGai wrote: >> Greg KH wrote: >>> On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: >>>> [PATCH 1/3] add a private data field within kobj_attribute structure. >>>> >>>> This patch add a private data field, declared as void *, within >>>> kobj_attribute >>>> structure. The _show() and _store() method in the sysfs attribute entries >>>> can >>>> refer this information to identify what entry is accessed. >>>> It makes easier to share a single method implementation with several >>>> similar >>>> entries, like ones to export the list of capabilities the running kernel >>>> supports. >>>> >>>> Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> >>>> -- >>>> Documentation/kobject.txt | 6 ++++++ >>> That's good, but you didn't modify the sample/kobject/ file to use the >>> new void pointer, instead of the strcmp() call. >> The 3/3 of patches updates sample/kobject to use the new void pointer. >> Do you want it to replace strcmp() examples completly? > > Doh, I totally missed that one, very sorry. I'll be glad to take > patches 1 and 3 in my tree, if you want me to. I want them to be upstreamed, no need to say. BTW, how do you think about the second patch which provides the most practical feature? Thanks for your reviewing. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-25 10:04 ` Kohei KaiGai @ 2008-02-26 20:09 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2008-02-26 20:09 UTC (permalink / raw) To: Kohei KaiGai; +Cc: morgan, serue, linux-security-module, linux-kernel On Mon, Feb 25, 2008 at 07:04:03PM +0900, Kohei KaiGai wrote: > Greg KH wrote: >> On Mon, Feb 25, 2008 at 03:57:44PM +0900, Kohei KaiGai wrote: >>> Greg KH wrote: >>>> On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: >>>>> [PATCH 1/3] add a private data field within kobj_attribute structure. >>>>> >>>>> This patch add a private data field, declared as void *, within >>>>> kobj_attribute >>>>> structure. The _show() and _store() method in the sysfs attribute >>>>> entries can >>>>> refer this information to identify what entry is accessed. >>>>> It makes easier to share a single method implementation with several >>>>> similar >>>>> entries, like ones to export the list of capabilities the running >>>>> kernel >>>>> supports. >>>>> >>>>> Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> >>>>> -- >>>>> Documentation/kobject.txt | 6 ++++++ >>>> That's good, but you didn't modify the sample/kobject/ file to use the >>>> new void pointer, instead of the strcmp() call. >>> The 3/3 of patches updates sample/kobject to use the new void pointer. >>> Do you want it to replace strcmp() examples completly? >> Doh, I totally missed that one, very sorry. I'll be glad to take >> patches 1 and 3 in my tree, if you want me to. > > I want them to be upstreamed, no need to say. > > BTW, how do you think about the second patch which provides the most > practical feature? I personally have no opinion on this patch, sorry. thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-25 6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai 2008-02-25 6:51 ` Greg KH @ 2008-02-28 5:49 ` Valdis.Kletnieks 2008-03-03 4:42 ` Kohei KaiGai 1 sibling, 1 reply; 32+ messages in thread From: Valdis.Kletnieks @ 2008-02-28 5:49 UTC (permalink / raw) To: Kohei KaiGai; +Cc: greg, morgan, serue, linux-security-module, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1431 bytes --] On Mon, 25 Feb 2008 15:10:27 +0900, Kohei KaiGai said: > [PATCH 1/3] add a private data field within kobj_attribute structure. > diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt > index bf3256e..efa5d71 100644 > --- a/Documentation/kobject.txt > +++ b/Documentation/kobject.txt > @@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created > with the kobject_create_and_add(), can be of type kobj_attribute, so no > special custom attribute is needed to be created. > > +The simple kobj_attribute is prototyped at include/linux/kobject.h, and can > +contain your own show()/store() method and private data. > +When an attribute is accessed, these methods are invoked with kobject, > +kobj_attribute and read/write buffer. The method can refer the private data > +via given kobj_attribute, to show/store itself in the text representation. > + > See the example module, samples/kobject/kobject-example.c for an > implementation of a simple kobject and attributes. OK, I'm an idiot, so I re-read this several times, and looked at patch 3/3 that added the sample code, and I'm still confoozled. Who creates/destroys/manages this "read/write buffer", and/or how does the method know how large a buffer is available, so (for example) it can use the strn* versions of string functions to be sure not to run off the end? Does this buffer have any lifetime rules attached to it? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) 2008-02-28 5:49 ` Valdis.Kletnieks @ 2008-03-03 4:42 ` Kohei KaiGai 0 siblings, 0 replies; 32+ messages in thread From: Kohei KaiGai @ 2008-03-03 4:42 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: greg, morgan, serue, linux-security-module, linux-kernel Valdis.Kletnieks@vt.edu wrote: > On Mon, 25 Feb 2008 15:10:27 +0900, Kohei KaiGai said: >> [PATCH 1/3] add a private data field within kobj_attribute structure. > >> diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt >> index bf3256e..efa5d71 100644 >> --- a/Documentation/kobject.txt >> +++ b/Documentation/kobject.txt >> @@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created >> with the kobject_create_and_add(), can be of type kobj_attribute, so no >> special custom attribute is needed to be created. >> >> +The simple kobj_attribute is prototyped at include/linux/kobject.h, and can >> +contain your own show()/store() method and private data. >> +When an attribute is accessed, these methods are invoked with kobject, >> +kobj_attribute and read/write buffer. The method can refer the private data >> +via given kobj_attribute, to show/store itself in the text representation. >> + >> See the example module, samples/kobject/kobject-example.c for an >> implementation of a simple kobject and attributes. > > OK, I'm an idiot, so I re-read this several times, and looked at patch 3/3 > that added the sample code, and I'm still confoozled. > > Who creates/destroys/manages this "read/write buffer", and/or how does the > method know how large a buffer is available, so (for example) it can use the > strn* versions of string functions to be sure not to run off the end? Does > this buffer have any lifetime rules attached to it? This "read/write buffer" is managed by sysfs filesystem. Sysfs is invoked via kernel VFS subsystem, when user calls read(2) or write(2). In the read(2) case, sysfs_read_file() is invoked, allocates a page for buffer, and calls the show() method to generate the containts of this pseudo file entry. Therefore, show() and store() method does not need to manage this buffer. When store() method is invoked with data from userspace, sysfs terminate it with '\0' implicitly. The size of buffer is also limited to PAGE_SIZE implicitly. Can you make it clear? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 2/3] exporting capability name/code pairs (final#2) 2008-02-25 6:06 [PATCH 0/3] exporting capability name/code pairs (final#2) Kohei KaiGai 2008-02-25 6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai @ 2008-02-25 6:10 ` Kohei KaiGai 2008-02-26 14:55 ` Andrew G. Morgan 2008-02-25 6:10 ` [PATCH 3/3] a new example to use kobject/kobj_attribute (final#2) Kohei KaiGai 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei 3 siblings, 1 reply; 32+ messages in thread From: Kohei KaiGai @ 2008-02-25 6:10 UTC (permalink / raw) To: greg, morgan, serue; +Cc: Kohei KaiGai, linux-security-module, linux-kernel [PATCH 2/3] exporting capability name/code pairs This patch enables to export code/name pairs of capabilities the running kernel supported. A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN at 2.6.25. However, we have no interface to disclose what capabilities are supported on the running kernel. Thus, we have to maintain libcap version in appropriate one synchronously. This patch enables libcap to collect the list of capabilities at run time, and provide them for users. It helps to improve portability of library. It exports these information as regular files under /sys/kernel/capability. The numeric node exports its name, the symbolic node exports its code. Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> -- Documentation/ABI/testing/sysfs-kernel-capability | 23 +++++ scripts/mkcapnames.sh | 44 +++++++++ security/Makefile | 9 ++ security/commoncap.c | 99 +++++++++++++++++++++ 4 files changed, 175 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-kernel-capability b/Documentation/ABI/testing/sysfs-kernel-capability index e69de29..d4a14e7 100644 --- a/Documentation/ABI/testing/sysfs-kernel-capability +++ b/Documentation/ABI/testing/sysfs-kernel-capability @@ -0,0 +1,23 @@ +What: /sys/kernel/capability +Date: Feb 2008 +Contact: KaiGai Kohei <kaigai@ak.jp.nec.com> +Description: + The entries under /sys/kernel/capability are used to export + the list of capabilities the running kernel supports. + + - /sys/kernel/capability/version + returns the most preferable version number for the + running kernel. + e.g) $ cat /sys/kernel/capability/version + 0x20071026 + + - /sys/kernel/capability/code/<numerical representation> + returns its symbolic representation, on reading. + e.g) $ cat /sys/kernel/capability/codes/30 + cap_audit_control + + - /sys/kernel/capability/name/<symbolic representation> + returns its numerical representation, on reading. + e.g) $ cat /sys/kernel/capability/names/cap_sys_pacct + 20 + diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh index e69de29..5d36d52 100644 --- a/scripts/mkcapnames.sh +++ b/scripts/mkcapnames.sh @@ -0,0 +1,44 @@ +#!/bin/sh + +# +# generate a cap_names.h file from include/linux/capability.h +# + +CAPHEAD="`dirname $0`/../include/linux/capability.h" +REGEXP='^#define CAP_[A-Z_]+[ ]+[0-9]+$' +NUMCAP=`cat "$CAPHEAD" | egrep -c "$REGEXP"` + +echo '#ifndef CAP_NAMES_H' +echo '#define CAP_NAMES_H' +echo +echo '/*' +echo ' * Do NOT edit this file directly.' +echo ' * This file is generated from include/linux/capability.h automatically' +echo ' */' +echo +echo '#if !defined(SYSFS_CAP_NAME_ENTRY) || !defined(SYSFS_CAP_CODE_ENTRY)' +echo '#error cap_names.h should be included from security/capability.c' +echo '#else' +echo "#if $NUMCAP != CAP_LAST_CAP + 1" +echo '#error mkcapnames.sh cannot collect capabilities correctly' +echo '#else' +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("SYSFS_CAP_NAME_ENTRY(%s,%s);\n", tolower($2), $2); }' +echo +echo 'static struct attribute *capability_name_attrs[] = {' +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("\t&%s_name_attr.attr,\n", tolower($2)); } END { print "\tNULL," }' +echo '};' + +echo +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("SYSFS_CAP_CODE_ENTRY(%s,%s);\n", tolower($2), $2); }' +echo +echo 'static struct attribute *capability_code_attrs[] = {' +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("\t&%s_code_attr.attr,\n", tolower($2)); } END { print "\tNULL," }' +echo '};' + +echo '#endif' +echo '#endif' +echo '#endif' diff --git a/security/Makefile b/security/Makefile index 9e8b025..4093e3e 100644 --- a/security/Makefile +++ b/security/Makefile @@ -18,3 +18,12 @@ obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o obj-$(CONFIG_SECURITY_SMACK) += commoncap.o smack/built-in.o obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o + +# cap_names.h contains the code/name pair of capabilities. +# It is generated using include/linux/capability.h automatically. +$(obj)/commoncap.o: $(obj)/cap_names.h +quiet_cmd_cap_names = CAPS $@ + cmd_cap_names = /bin/sh $(srctree)/scripts/mkcapnames.sh > $@ +targets += cap_names.h +$(obj)/cap_names.h: $(srctree)/scripts/mkcapnames.sh $(srctree)/include/linux/capability.h FORCE + $(call if_changed,cap_names) diff --git a/security/commoncap.c b/security/commoncap.c index 5aba826..9483fa9 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -24,6 +24,8 @@ #include <linux/hugetlb.h> #include <linux/mount.h> #include <linux/sched.h> +#include <linux/kobject.h> +#include <linux/sysfs.h> /* Global security state */ @@ -637,3 +639,100 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages) return __vm_enough_memory(mm, pages, cap_sys_admin); } +/* + * Export the list of capabilities on /sys/kernel/capability + */ +static struct kobject *capability_kobj; + +static ssize_t capability_name_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buffer) +{ + /* It returns numerical representation of capability. */ + return scnprintf(buffer, PAGE_SIZE, "%ld\n", (long) attr->data); +} + +static ssize_t capability_code_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buffer) +{ + /* It returns symbolic representation of capability. */ + return scnprintf(buffer, PAGE_SIZE, "%s\n", (char *) attr->data); +} + +static ssize_t capability_version_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buffer) +{ + return scnprintf(buffer, PAGE_SIZE, "0x%08x\n", + _LINUX_CAPABILITY_VERSION); +} + +#define SYSFS_CAP_NAME_ENTRY(_name,_code) \ + static struct kobj_attribute _name##_name_attr = \ + __ATTR_DATA(_name, 0444, capability_name_show, NULL, (long)(_code)) + +#define SYSFS_CAP_CODE_ENTRY(_name,_code) \ + static struct kobj_attribute _name##_code_attr = \ + __ATTR_DATA(_code, 0444, capability_code_show, NULL, __stringify(_name)) + +/* + * capability_attrs[] is generated automatically by scripts/mkcapnames.sh + * This script parses include/linux/capability.h + */ +#include "cap_names.h" + +static struct attribute_group capability_name_attr_group = { + .name = "names", + .attrs = capability_name_attrs, +}; + +static struct attribute_group capability_code_attr_group = { + .name = "codes", + .attrs = capability_code_attrs, +}; + +static struct kobj_attribute cap_version_attr = + __ATTR(version, 0444, capability_version_show, NULL); + +static int __init capability_export_names(void) +{ + int rc = -ENOMEM; + + /* make /sys/kernel/capability */ + capability_kobj = kobject_create_and_add("capability", kernel_kobj); + if (!capability_kobj) + goto error0; + + /* make /sys/kernel/capability/names */ + rc = sysfs_create_group(capability_kobj, + &capability_name_attr_group); + if (rc) + goto error1; + + /* make /sys/kernel/capability/codes */ + rc = sysfs_create_group(capability_kobj, + &capability_code_attr_group); + if (rc) + goto error2; + + /* make /sys/kernel/capability/version */ + rc = sysfs_create_file(capability_kobj, + &cap_version_attr.attr); + if (rc) + goto error3; + + return 0; + +error3: + sysfs_remove_group(capability_kobj, &capability_code_attr_group); +error2: + sysfs_remove_group(capability_kobj, &capability_name_attr_group); +error1: + kobject_put(capability_kobj); +error0: + printk(KERN_ERR "Unable to export capabilities\n"); + + return rc; +} +__initcall(capability_export_names); -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH 2/3] exporting capability name/code pairs (final#2) 2008-02-25 6:10 ` [PATCH 2/3] exporting capability name/code pairs (final#2) Kohei KaiGai @ 2008-02-26 14:55 ` Andrew G. Morgan 2008-02-26 20:58 ` Serge E. Hallyn 0 siblings, 1 reply; 32+ messages in thread From: Andrew G. Morgan @ 2008-02-26 14:55 UTC (permalink / raw) To: Kohei KaiGai; +Cc: greg, serue, linux-security-module, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Acked-by: Andrew G. Morgan <morgan@kernel.org> Tested-by: Andrew G. Morgan <morgan@kernel.org> Cheers Andrew Kohei KaiGai wrote: | [PATCH 2/3] exporting capability name/code pairs | | This patch enables to export code/name pairs of capabilities the running | kernel supported. | | A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN | at 2.6.25. However, we have no interface to disclose what capabilities | are supported on the running kernel. Thus, we have to maintain libcap | version in appropriate one synchronously. | | This patch enables libcap to collect the list of capabilities at run time, | and provide them for users. It helps to improve portability of library. | | It exports these information as regular files under /sys/kernel/capability. | The numeric node exports its name, the symbolic node exports its code. | | Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> | -- | Documentation/ABI/testing/sysfs-kernel-capability | 23 +++++ | scripts/mkcapnames.sh | 44 +++++++++ | security/Makefile | 9 ++ | security/commoncap.c | 99 +++++++++++++++++++++ | 4 files changed, 175 insertions(+), 0 deletions(-) | | diff --git a/Documentation/ABI/testing/sysfs-kernel-capability b/Documentation/ABI/testing/sysfs-kernel-capability | index e69de29..d4a14e7 100644 | --- a/Documentation/ABI/testing/sysfs-kernel-capability | +++ b/Documentation/ABI/testing/sysfs-kernel-capability | @@ -0,0 +1,23 @@ | +What: /sys/kernel/capability | +Date: Feb 2008 | +Contact: KaiGai Kohei <kaigai@ak.jp.nec.com> | +Description: | + The entries under /sys/kernel/capability are used to export | + the list of capabilities the running kernel supports. | + | + - /sys/kernel/capability/version | + returns the most preferable version number for the | + running kernel. | + e.g) $ cat /sys/kernel/capability/version | + 0x20071026 | + | + - /sys/kernel/capability/code/<numerical representation> | + returns its symbolic representation, on reading. | + e.g) $ cat /sys/kernel/capability/codes/30 | + cap_audit_control | + | + - /sys/kernel/capability/name/<symbolic representation> | + returns its numerical representation, on reading. | + e.g) $ cat /sys/kernel/capability/names/cap_sys_pacct | + 20 | + | diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh | index e69de29..5d36d52 100644 | --- a/scripts/mkcapnames.sh | +++ b/scripts/mkcapnames.sh | @@ -0,0 +1,44 @@ | +#!/bin/sh | + | +# | +# generate a cap_names.h file from include/linux/capability.h | +# | + | +CAPHEAD="`dirname $0`/../include/linux/capability.h" | +REGEXP='^#define CAP_[A-Z_]+[ ]+[0-9]+$' | +NUMCAP=`cat "$CAPHEAD" | egrep -c "$REGEXP"` | + | +echo '#ifndef CAP_NAMES_H' | +echo '#define CAP_NAMES_H' | +echo | +echo '/*' | +echo ' * Do NOT edit this file directly.' | +echo ' * This file is generated from include/linux/capability.h automatically' | +echo ' */' | +echo | +echo '#if !defined(SYSFS_CAP_NAME_ENTRY) || !defined(SYSFS_CAP_CODE_ENTRY)' | +echo '#error cap_names.h should be included from security/capability.c' | +echo '#else' | +echo "#if $NUMCAP != CAP_LAST_CAP + 1" | +echo '#error mkcapnames.sh cannot collect capabilities correctly' | +echo '#else' | +cat "$CAPHEAD" | egrep "$REGEXP" \ | + | awk '{ printf("SYSFS_CAP_NAME_ENTRY(%s,%s);\n", tolower($2), $2); }' | +echo | +echo 'static struct attribute *capability_name_attrs[] = {' | +cat "$CAPHEAD" | egrep "$REGEXP" \ | + | awk '{ printf("\t&%s_name_attr.attr,\n", tolower($2)); } END { print "\tNULL," }' | +echo '};' | + | +echo | +cat "$CAPHEAD" | egrep "$REGEXP" \ | + | awk '{ printf("SYSFS_CAP_CODE_ENTRY(%s,%s);\n", tolower($2), $2); }' | +echo | +echo 'static struct attribute *capability_code_attrs[] = {' | +cat "$CAPHEAD" | egrep "$REGEXP" \ | + | awk '{ printf("\t&%s_code_attr.attr,\n", tolower($2)); } END { print "\tNULL," }' | +echo '};' | + | +echo '#endif' | +echo '#endif' | +echo '#endif' | diff --git a/security/Makefile b/security/Makefile | index 9e8b025..4093e3e 100644 | --- a/security/Makefile | +++ b/security/Makefile | @@ -18,3 +18,12 @@ obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o | obj-$(CONFIG_SECURITY_SMACK) += commoncap.o smack/built-in.o | obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o | obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o | + | +# cap_names.h contains the code/name pair of capabilities. | +# It is generated using include/linux/capability.h automatically. | +$(obj)/commoncap.o: $(obj)/cap_names.h | +quiet_cmd_cap_names = CAPS $@ | + cmd_cap_names = /bin/sh $(srctree)/scripts/mkcapnames.sh > $@ | +targets += cap_names.h | +$(obj)/cap_names.h: $(srctree)/scripts/mkcapnames.sh $(srctree)/include/linux/capability.h FORCE | + $(call if_changed,cap_names) | diff --git a/security/commoncap.c b/security/commoncap.c | index 5aba826..9483fa9 100644 | --- a/security/commoncap.c | +++ b/security/commoncap.c | @@ -24,6 +24,8 @@ | #include <linux/hugetlb.h> | #include <linux/mount.h> | #include <linux/sched.h> | +#include <linux/kobject.h> | +#include <linux/sysfs.h> | | /* Global security state */ | | @@ -637,3 +639,100 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages) | return __vm_enough_memory(mm, pages, cap_sys_admin); | } | | +/* | + * Export the list of capabilities on /sys/kernel/capability | + */ | +static struct kobject *capability_kobj; | + | +static ssize_t capability_name_show(struct kobject *kobj, | + struct kobj_attribute *attr, | + char *buffer) | +{ | + /* It returns numerical representation of capability. */ | + return scnprintf(buffer, PAGE_SIZE, "%ld\n", (long) attr->data); | +} | + | +static ssize_t capability_code_show(struct kobject *kobj, | + struct kobj_attribute *attr, | + char *buffer) | +{ | + /* It returns symbolic representation of capability. */ | + return scnprintf(buffer, PAGE_SIZE, "%s\n", (char *) attr->data); | +} | + | +static ssize_t capability_version_show(struct kobject *kobj, | + struct kobj_attribute *attr, | + char *buffer) | +{ | + return scnprintf(buffer, PAGE_SIZE, "0x%08x\n", | + _LINUX_CAPABILITY_VERSION); | +} | + | +#define SYSFS_CAP_NAME_ENTRY(_name,_code) \ | + static struct kobj_attribute _name##_name_attr = \ | + __ATTR_DATA(_name, 0444, capability_name_show, NULL, (long)(_code)) | + | +#define SYSFS_CAP_CODE_ENTRY(_name,_code) \ | + static struct kobj_attribute _name##_code_attr = \ | + __ATTR_DATA(_code, 0444, capability_code_show, NULL, __stringify(_name)) | + | +/* | + * capability_attrs[] is generated automatically by scripts/mkcapnames.sh | + * This script parses include/linux/capability.h | + */ | +#include "cap_names.h" | + | +static struct attribute_group capability_name_attr_group = { | + .name = "names", | + .attrs = capability_name_attrs, | +}; | + | +static struct attribute_group capability_code_attr_group = { | + .name = "codes", | + .attrs = capability_code_attrs, | +}; | + | +static struct kobj_attribute cap_version_attr = | + __ATTR(version, 0444, capability_version_show, NULL); | + | +static int __init capability_export_names(void) | +{ | + int rc = -ENOMEM; | + | + /* make /sys/kernel/capability */ | + capability_kobj = kobject_create_and_add("capability", kernel_kobj); | + if (!capability_kobj) | + goto error0; | + | + /* make /sys/kernel/capability/names */ | + rc = sysfs_create_group(capability_kobj, | + &capability_name_attr_group); | + if (rc) | + goto error1; | + | + /* make /sys/kernel/capability/codes */ | + rc = sysfs_create_group(capability_kobj, | + &capability_code_attr_group); | + if (rc) | + goto error2; | + | + /* make /sys/kernel/capability/version */ | + rc = sysfs_create_file(capability_kobj, | + &cap_version_attr.attr); | + if (rc) | + goto error3; | + | + return 0; | + | +error3: | + sysfs_remove_group(capability_kobj, &capability_code_attr_group); | +error2: | + sysfs_remove_group(capability_kobj, &capability_name_attr_group); | +error1: | + kobject_put(capability_kobj); | +error0: | + printk(KERN_ERR "Unable to export capabilities\n"); | + | + return rc; | +} | +__initcall(capability_export_names); | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFHxChT+bHCR3gb8jsRAtnIAJ9EZKZ8Uw1WZE0GdGc2SRuuEdqm5QCcCUm2 Dp+6/phU4jLCDo6jsNKJd9A= =6DqN -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 2/3] exporting capability name/code pairs (final#2) 2008-02-26 14:55 ` Andrew G. Morgan @ 2008-02-26 20:58 ` Serge E. Hallyn 2008-03-07 4:30 ` Kohei KaiGai 0 siblings, 1 reply; 32+ messages in thread From: Serge E. Hallyn @ 2008-02-26 20:58 UTC (permalink / raw) To: Andrew G. Morgan Cc: Kohei KaiGai, greg, serue, linux-security-module, linux-kernel Quoting Andrew G. Morgan (morgan@kernel.org): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Acked-by: Andrew G. Morgan <morgan@kernel.org> > Tested-by: Andrew G. Morgan <morgan@kernel.org> Also Acked-by: Serge Hallyn <serue@us.ibm.com> Tested-by: Serge Hallyn <serue@us.ibm.com> thanks, -serge (plus you taught me a thing or two about kernel makefiles...) > > Cheers > > Andrew > > Kohei KaiGai wrote: > | [PATCH 2/3] exporting capability name/code pairs > | > | This patch enables to export code/name pairs of capabilities the running > | kernel supported. > | > | A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN > | at 2.6.25. However, we have no interface to disclose what capabilities > | are supported on the running kernel. Thus, we have to maintain libcap > | version in appropriate one synchronously. > | > | This patch enables libcap to collect the list of capabilities at run > time, > | and provide them for users. It helps to improve portability of library. > | > | It exports these information as regular files under > /sys/kernel/capability. > | The numeric node exports its name, the symbolic node exports its code. > | > | Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> > | -- > | Documentation/ABI/testing/sysfs-kernel-capability | 23 +++++ > | scripts/mkcapnames.sh | 44 +++++++++ > | security/Makefile | 9 ++ > | security/commoncap.c | 99 > +++++++++++++++++++++ > | 4 files changed, 175 insertions(+), 0 deletions(-) > | > | diff --git a/Documentation/ABI/testing/sysfs-kernel-capability > b/Documentation/ABI/testing/sysfs-kernel-capability > | index e69de29..d4a14e7 100644 > | --- a/Documentation/ABI/testing/sysfs-kernel-capability > | +++ b/Documentation/ABI/testing/sysfs-kernel-capability > | @@ -0,0 +1,23 @@ > | +What: /sys/kernel/capability > | +Date: Feb 2008 > | +Contact: KaiGai Kohei <kaigai@ak.jp.nec.com> > | +Description: > | + The entries under /sys/kernel/capability are used to export > | + the list of capabilities the running kernel supports. > | + > | + - /sys/kernel/capability/version > | + returns the most preferable version number for the > | + running kernel. > | + e.g) $ cat /sys/kernel/capability/version > | + 0x20071026 > | + > | + - /sys/kernel/capability/code/<numerical representation> > | + returns its symbolic representation, on reading. > | + e.g) $ cat /sys/kernel/capability/codes/30 > | + cap_audit_control > | + > | + - /sys/kernel/capability/name/<symbolic representation> > | + returns its numerical representation, on reading. > | + e.g) $ cat /sys/kernel/capability/names/cap_sys_pacct > | + 20 > | + > | diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh > | index e69de29..5d36d52 100644 > | --- a/scripts/mkcapnames.sh > | +++ b/scripts/mkcapnames.sh > | @@ -0,0 +1,44 @@ > | +#!/bin/sh > | + > | +# > | +# generate a cap_names.h file from include/linux/capability.h > | +# > | + > | +CAPHEAD="`dirname $0`/../include/linux/capability.h" > | +REGEXP='^#define CAP_[A-Z_]+[ ]+[0-9]+$' > | +NUMCAP=`cat "$CAPHEAD" | egrep -c "$REGEXP"` > | + > | +echo '#ifndef CAP_NAMES_H' > | +echo '#define CAP_NAMES_H' > | +echo > | +echo '/*' > | +echo ' * Do NOT edit this file directly.' > | +echo ' * This file is generated from include/linux/capability.h > automatically' > | +echo ' */' > | +echo > | +echo '#if !defined(SYSFS_CAP_NAME_ENTRY) || > !defined(SYSFS_CAP_CODE_ENTRY)' > | +echo '#error cap_names.h should be included from security/capability.c' > | +echo '#else' > | +echo "#if $NUMCAP != CAP_LAST_CAP + 1" > | +echo '#error mkcapnames.sh cannot collect capabilities correctly' > | +echo '#else' > | +cat "$CAPHEAD" | egrep "$REGEXP" \ > | + | awk '{ printf("SYSFS_CAP_NAME_ENTRY(%s,%s);\n", tolower($2), > $2); }' > | +echo > | +echo 'static struct attribute *capability_name_attrs[] = {' > | +cat "$CAPHEAD" | egrep "$REGEXP" \ > | + | awk '{ printf("\t&%s_name_attr.attr,\n", tolower($2)); } END { > print "\tNULL," }' > | +echo '};' > | + > | +echo > | +cat "$CAPHEAD" | egrep "$REGEXP" \ > | + | awk '{ printf("SYSFS_CAP_CODE_ENTRY(%s,%s);\n", tolower($2), > $2); }' > | +echo > | +echo 'static struct attribute *capability_code_attrs[] = {' > | +cat "$CAPHEAD" | egrep "$REGEXP" \ > | + | awk '{ printf("\t&%s_code_attr.attr,\n", tolower($2)); } END { > print "\tNULL," }' > | +echo '};' > | + > | +echo '#endif' > | +echo '#endif' > | +echo '#endif' > | diff --git a/security/Makefile b/security/Makefile > | index 9e8b025..4093e3e 100644 > | --- a/security/Makefile > | +++ b/security/Makefile > | @@ -18,3 +18,12 @@ obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o > | obj-$(CONFIG_SECURITY_SMACK) += commoncap.o smack/built-in.o > | obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o > | obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o > | + > | +# cap_names.h contains the code/name pair of capabilities. > | +# It is generated using include/linux/capability.h automatically. > | +$(obj)/commoncap.o: $(obj)/cap_names.h > | +quiet_cmd_cap_names = CAPS $@ > | + cmd_cap_names = /bin/sh $(srctree)/scripts/mkcapnames.sh > $@ > | +targets += cap_names.h > | +$(obj)/cap_names.h: $(srctree)/scripts/mkcapnames.sh > $(srctree)/include/linux/capability.h FORCE > | + $(call if_changed,cap_names) > | diff --git a/security/commoncap.c b/security/commoncap.c > | index 5aba826..9483fa9 100644 > | --- a/security/commoncap.c > | +++ b/security/commoncap.c > | @@ -24,6 +24,8 @@ > | #include <linux/hugetlb.h> > | #include <linux/mount.h> > | #include <linux/sched.h> > | +#include <linux/kobject.h> > | +#include <linux/sysfs.h> > | > | /* Global security state */ > | > | @@ -637,3 +639,100 @@ int cap_vm_enough_memory(struct mm_struct *mm, > long pages) > | return __vm_enough_memory(mm, pages, cap_sys_admin); > | } > | > | +/* > | + * Export the list of capabilities on /sys/kernel/capability > | + */ > | +static struct kobject *capability_kobj; > | + > | +static ssize_t capability_name_show(struct kobject *kobj, > | + struct kobj_attribute *attr, > | + char *buffer) > | +{ > | + /* It returns numerical representation of capability. */ > | + return scnprintf(buffer, PAGE_SIZE, "%ld\n", (long) attr->data); > | +} > | + > | +static ssize_t capability_code_show(struct kobject *kobj, > | + struct kobj_attribute *attr, > | + char *buffer) > | +{ > | + /* It returns symbolic representation of capability. */ > | + return scnprintf(buffer, PAGE_SIZE, "%s\n", (char *) attr->data); > | +} > | + > | +static ssize_t capability_version_show(struct kobject *kobj, > | + struct kobj_attribute *attr, > | + char *buffer) > | +{ > | + return scnprintf(buffer, PAGE_SIZE, "0x%08x\n", > | + _LINUX_CAPABILITY_VERSION); > | +} > | + > | +#define SYSFS_CAP_NAME_ENTRY(_name,_code) \ > | + static struct kobj_attribute _name##_name_attr = \ > | + __ATTR_DATA(_name, 0444, capability_name_show, NULL, (long)(_code)) > | + > | +#define SYSFS_CAP_CODE_ENTRY(_name,_code) \ > | + static struct kobj_attribute _name##_code_attr = \ > | + __ATTR_DATA(_code, 0444, capability_code_show, NULL, > __stringify(_name)) > | + > | +/* > | + * capability_attrs[] is generated automatically by > scripts/mkcapnames.sh > | + * This script parses include/linux/capability.h > | + */ > | +#include "cap_names.h" > | + > | +static struct attribute_group capability_name_attr_group = { > | + .name = "names", > | + .attrs = capability_name_attrs, > | +}; > | + > | +static struct attribute_group capability_code_attr_group = { > | + .name = "codes", > | + .attrs = capability_code_attrs, > | +}; > | + > | +static struct kobj_attribute cap_version_attr = > | + __ATTR(version, 0444, capability_version_show, NULL); > | + > | +static int __init capability_export_names(void) > | +{ > | + int rc = -ENOMEM; > | + > | + /* make /sys/kernel/capability */ > | + capability_kobj = kobject_create_and_add("capability", kernel_kobj); > | + if (!capability_kobj) > | + goto error0; > | + > | + /* make /sys/kernel/capability/names */ > | + rc = sysfs_create_group(capability_kobj, > | + &capability_name_attr_group); > | + if (rc) > | + goto error1; > | + > | + /* make /sys/kernel/capability/codes */ > | + rc = sysfs_create_group(capability_kobj, > | + &capability_code_attr_group); > | + if (rc) > | + goto error2; > | + > | + /* make /sys/kernel/capability/version */ > | + rc = sysfs_create_file(capability_kobj, > | + &cap_version_attr.attr); > | + if (rc) > | + goto error3; > | + > | + return 0; > | + > | +error3: > | + sysfs_remove_group(capability_kobj, &capability_code_attr_group); > | +error2: > | + sysfs_remove_group(capability_kobj, &capability_name_attr_group); > | +error1: > | + kobject_put(capability_kobj); > | +error0: > | + printk(KERN_ERR "Unable to export capabilities\n"); > | + > | + return rc; > | +} > | +__initcall(capability_export_names); > | > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFHxChT+bHCR3gb8jsRAtnIAJ9EZKZ8Uw1WZE0GdGc2SRuuEdqm5QCcCUm2 > Dp+6/phU4jLCDo6jsNKJd9A= > =6DqN > -----END PGP SIGNATURE----- > - > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 2/3] exporting capability name/code pairs (final#2) 2008-02-26 20:58 ` Serge E. Hallyn @ 2008-03-07 4:30 ` Kohei KaiGai 2008-03-07 4:53 ` Greg KH 0 siblings, 1 reply; 32+ messages in thread From: Kohei KaiGai @ 2008-03-07 4:30 UTC (permalink / raw) To: Serge E. Hallyn Cc: Andrew G. Morgan, greg, linux-security-module, linux-kernel Who can pick up this patch to the upstreamed tree? It's unclear for me, because no one is explicitly listed as a maintainer of capabilities.... # I believe we need no more technical discussion any more # in this feature. Serge E. Hallyn wrote: > Quoting Andrew G. Morgan (morgan@kernel.org): >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Acked-by: Andrew G. Morgan <morgan@kernel.org> >> Tested-by: Andrew G. Morgan <morgan@kernel.org> > > Also > > Acked-by: Serge Hallyn <serue@us.ibm.com> > Tested-by: Serge Hallyn <serue@us.ibm.com> > > thanks, > -serge > > (plus you taught me a thing or two about kernel makefiles...) Sorry, I made an oversight. However, I'm not an expert of kernel makefiles. It follows the bottom of kernel/Makefile as an example. Thanks, >> Cheers >> >> Andrew >> >> Kohei KaiGai wrote: >> | [PATCH 2/3] exporting capability name/code pairs >> | >> | This patch enables to export code/name pairs of capabilities the running >> | kernel supported. >> | >> | A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN >> | at 2.6.25. However, we have no interface to disclose what capabilities >> | are supported on the running kernel. Thus, we have to maintain libcap >> | version in appropriate one synchronously. >> | >> | This patch enables libcap to collect the list of capabilities at run >> time, >> | and provide them for users. It helps to improve portability of library. >> | >> | It exports these information as regular files under >> /sys/kernel/capability. >> | The numeric node exports its name, the symbolic node exports its code. >> | >> | Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> >> | -- >> | Documentation/ABI/testing/sysfs-kernel-capability | 23 +++++ >> | scripts/mkcapnames.sh | 44 +++++++++ >> | security/Makefile | 9 ++ >> | security/commoncap.c | 99 >> +++++++++++++++++++++ >> | 4 files changed, 175 insertions(+), 0 deletions(-) >> | >> | diff --git a/Documentation/ABI/testing/sysfs-kernel-capability >> b/Documentation/ABI/testing/sysfs-kernel-capability >> | index e69de29..d4a14e7 100644 >> | --- a/Documentation/ABI/testing/sysfs-kernel-capability >> | +++ b/Documentation/ABI/testing/sysfs-kernel-capability >> | @@ -0,0 +1,23 @@ >> | +What: /sys/kernel/capability >> | +Date: Feb 2008 >> | +Contact: KaiGai Kohei <kaigai@ak.jp.nec.com> >> | +Description: >> | + The entries under /sys/kernel/capability are used to export >> | + the list of capabilities the running kernel supports. >> | + >> | + - /sys/kernel/capability/version >> | + returns the most preferable version number for the >> | + running kernel. >> | + e.g) $ cat /sys/kernel/capability/version >> | + 0x20071026 >> | + >> | + - /sys/kernel/capability/code/<numerical representation> >> | + returns its symbolic representation, on reading. >> | + e.g) $ cat /sys/kernel/capability/codes/30 >> | + cap_audit_control >> | + >> | + - /sys/kernel/capability/name/<symbolic representation> >> | + returns its numerical representation, on reading. >> | + e.g) $ cat /sys/kernel/capability/names/cap_sys_pacct >> | + 20 >> | + >> | diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh >> | index e69de29..5d36d52 100644 >> | --- a/scripts/mkcapnames.sh >> | +++ b/scripts/mkcapnames.sh >> | @@ -0,0 +1,44 @@ >> | +#!/bin/sh >> | + >> | +# >> | +# generate a cap_names.h file from include/linux/capability.h >> | +# >> | + >> | +CAPHEAD="`dirname $0`/../include/linux/capability.h" >> | +REGEXP='^#define CAP_[A-Z_]+[ ]+[0-9]+$' >> | +NUMCAP=`cat "$CAPHEAD" | egrep -c "$REGEXP"` >> | + >> | +echo '#ifndef CAP_NAMES_H' >> | +echo '#define CAP_NAMES_H' >> | +echo >> | +echo '/*' >> | +echo ' * Do NOT edit this file directly.' >> | +echo ' * This file is generated from include/linux/capability.h >> automatically' >> | +echo ' */' >> | +echo >> | +echo '#if !defined(SYSFS_CAP_NAME_ENTRY) || >> !defined(SYSFS_CAP_CODE_ENTRY)' >> | +echo '#error cap_names.h should be included from security/capability.c' >> | +echo '#else' >> | +echo "#if $NUMCAP != CAP_LAST_CAP + 1" >> | +echo '#error mkcapnames.sh cannot collect capabilities correctly' >> | +echo '#else' >> | +cat "$CAPHEAD" | egrep "$REGEXP" \ >> | + | awk '{ printf("SYSFS_CAP_NAME_ENTRY(%s,%s);\n", tolower($2), >> $2); }' >> | +echo >> | +echo 'static struct attribute *capability_name_attrs[] = {' >> | +cat "$CAPHEAD" | egrep "$REGEXP" \ >> | + | awk '{ printf("\t&%s_name_attr.attr,\n", tolower($2)); } END { >> print "\tNULL," }' >> | +echo '};' >> | + >> | +echo >> | +cat "$CAPHEAD" | egrep "$REGEXP" \ >> | + | awk '{ printf("SYSFS_CAP_CODE_ENTRY(%s,%s);\n", tolower($2), >> $2); }' >> | +echo >> | +echo 'static struct attribute *capability_code_attrs[] = {' >> | +cat "$CAPHEAD" | egrep "$REGEXP" \ >> | + | awk '{ printf("\t&%s_code_attr.attr,\n", tolower($2)); } END { >> print "\tNULL," }' >> | +echo '};' >> | + >> | +echo '#endif' >> | +echo '#endif' >> | +echo '#endif' >> | diff --git a/security/Makefile b/security/Makefile >> | index 9e8b025..4093e3e 100644 >> | --- a/security/Makefile >> | +++ b/security/Makefile >> | @@ -18,3 +18,12 @@ obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o >> | obj-$(CONFIG_SECURITY_SMACK) += commoncap.o smack/built-in.o >> | obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o >> | obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o >> | + >> | +# cap_names.h contains the code/name pair of capabilities. >> | +# It is generated using include/linux/capability.h automatically. >> | +$(obj)/commoncap.o: $(obj)/cap_names.h >> | +quiet_cmd_cap_names = CAPS $@ >> | + cmd_cap_names = /bin/sh $(srctree)/scripts/mkcapnames.sh > $@ >> | +targets += cap_names.h >> | +$(obj)/cap_names.h: $(srctree)/scripts/mkcapnames.sh >> $(srctree)/include/linux/capability.h FORCE >> | + $(call if_changed,cap_names) >> | diff --git a/security/commoncap.c b/security/commoncap.c >> | index 5aba826..9483fa9 100644 >> | --- a/security/commoncap.c >> | +++ b/security/commoncap.c >> | @@ -24,6 +24,8 @@ >> | #include <linux/hugetlb.h> >> | #include <linux/mount.h> >> | #include <linux/sched.h> >> | +#include <linux/kobject.h> >> | +#include <linux/sysfs.h> >> | >> | /* Global security state */ >> | >> | @@ -637,3 +639,100 @@ int cap_vm_enough_memory(struct mm_struct *mm, >> long pages) >> | return __vm_enough_memory(mm, pages, cap_sys_admin); >> | } >> | >> | +/* >> | + * Export the list of capabilities on /sys/kernel/capability >> | + */ >> | +static struct kobject *capability_kobj; >> | + >> | +static ssize_t capability_name_show(struct kobject *kobj, >> | + struct kobj_attribute *attr, >> | + char *buffer) >> | +{ >> | + /* It returns numerical representation of capability. */ >> | + return scnprintf(buffer, PAGE_SIZE, "%ld\n", (long) attr->data); >> | +} >> | + >> | +static ssize_t capability_code_show(struct kobject *kobj, >> | + struct kobj_attribute *attr, >> | + char *buffer) >> | +{ >> | + /* It returns symbolic representation of capability. */ >> | + return scnprintf(buffer, PAGE_SIZE, "%s\n", (char *) attr->data); >> | +} >> | + >> | +static ssize_t capability_version_show(struct kobject *kobj, >> | + struct kobj_attribute *attr, >> | + char *buffer) >> | +{ >> | + return scnprintf(buffer, PAGE_SIZE, "0x%08x\n", >> | + _LINUX_CAPABILITY_VERSION); >> | +} >> | + >> | +#define SYSFS_CAP_NAME_ENTRY(_name,_code) \ >> | + static struct kobj_attribute _name##_name_attr = \ >> | + __ATTR_DATA(_name, 0444, capability_name_show, NULL, (long)(_code)) >> | + >> | +#define SYSFS_CAP_CODE_ENTRY(_name,_code) \ >> | + static struct kobj_attribute _name##_code_attr = \ >> | + __ATTR_DATA(_code, 0444, capability_code_show, NULL, >> __stringify(_name)) >> | + >> | +/* >> | + * capability_attrs[] is generated automatically by >> scripts/mkcapnames.sh >> | + * This script parses include/linux/capability.h >> | + */ >> | +#include "cap_names.h" >> | + >> | +static struct attribute_group capability_name_attr_group = { >> | + .name = "names", >> | + .attrs = capability_name_attrs, >> | +}; >> | + >> | +static struct attribute_group capability_code_attr_group = { >> | + .name = "codes", >> | + .attrs = capability_code_attrs, >> | +}; >> | + >> | +static struct kobj_attribute cap_version_attr = >> | + __ATTR(version, 0444, capability_version_show, NULL); >> | + >> | +static int __init capability_export_names(void) >> | +{ >> | + int rc = -ENOMEM; >> | + >> | + /* make /sys/kernel/capability */ >> | + capability_kobj = kobject_create_and_add("capability", kernel_kobj); >> | + if (!capability_kobj) >> | + goto error0; >> | + >> | + /* make /sys/kernel/capability/names */ >> | + rc = sysfs_create_group(capability_kobj, >> | + &capability_name_attr_group); >> | + if (rc) >> | + goto error1; >> | + >> | + /* make /sys/kernel/capability/codes */ >> | + rc = sysfs_create_group(capability_kobj, >> | + &capability_code_attr_group); >> | + if (rc) >> | + goto error2; >> | + >> | + /* make /sys/kernel/capability/version */ >> | + rc = sysfs_create_file(capability_kobj, >> | + &cap_version_attr.attr); >> | + if (rc) >> | + goto error3; >> | + >> | + return 0; >> | + >> | +error3: >> | + sysfs_remove_group(capability_kobj, &capability_code_attr_group); >> | +error2: >> | + sysfs_remove_group(capability_kobj, &capability_name_attr_group); >> | +error1: >> | + kobject_put(capability_kobj); >> | +error0: >> | + printk(KERN_ERR "Unable to export capabilities\n"); >> | + >> | + return rc; >> | +} >> | +__initcall(capability_export_names); >> | >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.2.6 (GNU/Linux) >> >> iD8DBQFHxChT+bHCR3gb8jsRAtnIAJ9EZKZ8Uw1WZE0GdGc2SRuuEdqm5QCcCUm2 >> Dp+6/phU4jLCDo6jsNKJd9A= >> =6DqN >> -----END PGP SIGNATURE----- >> - >> To unsubscribe from this list: send the line "unsubscribe >> linux-security-module" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > - > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 2/3] exporting capability name/code pairs (final#2) 2008-03-07 4:30 ` Kohei KaiGai @ 2008-03-07 4:53 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2008-03-07 4:53 UTC (permalink / raw) To: Kohei KaiGai Cc: Serge E. Hallyn, Andrew G. Morgan, linux-security-module, linux-kernel On Fri, Mar 07, 2008 at 01:30:52PM +0900, Kohei KaiGai wrote: > Who can pick up this patch to the upstreamed tree? > > It's unclear for me, because no one is explicitly listed > as a maintainer of capabilities.... If the security maintainer (Chris Wright) signs off on it, I'll be glad to take this through my tree as it does need the kobject changes to work properly. thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 3/3] a new example to use kobject/kobj_attribute (final#2) 2008-02-25 6:06 [PATCH 0/3] exporting capability name/code pairs (final#2) Kohei KaiGai 2008-02-25 6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai 2008-02-25 6:10 ` [PATCH 2/3] exporting capability name/code pairs (final#2) Kohei KaiGai @ 2008-02-25 6:10 ` Kohei KaiGai 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei 3 siblings, 0 replies; 32+ messages in thread From: Kohei KaiGai @ 2008-02-25 6:10 UTC (permalink / raw) To: Kohei KaiGai; +Cc: greg, morgan, serue, linux-security-module, linux-kernel [PATCH 3/3] a new example to use kobject/kobj_attribute This patch can provide a new exmple to use kobject and attribute. The _show() and _store() method can refer/store the private data field of kobj_attribute structure to know what entries are accessed by users. It will make easier to share a single _show()/_store() method with several entries. Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> -- samples/kobject/kobject-example.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/samples/kobject/kobject-example.c b/samples/kobject/kobject-example.c index 08d0d3f..5486a14 100644 --- a/samples/kobject/kobject-example.c +++ b/samples/kobject/kobject-example.c @@ -77,6 +77,35 @@ static struct kobj_attribute baz_attribute = static struct kobj_attribute bar_attribute = __ATTR(bar, 0666, b_show, b_store); +/* + * You can store a private data within 'data' field of kobj_attribute. + * It enables to share a single _show() or _store() method with several + * entries. + */ +static ssize_t integer_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buf) +{ + return scnprintf(buf, PAGE_SIZE, "%ld\n", (long) attr->data); +} + +static ssize_t integer_store(struct kobject *kobj, + struct kobj_attribute *attr, + const char *buf, size_t count) +{ + long code; + + sscanf(buf, "%ld", &code); + attr->data = (void *) code; + return count; +} + +static struct kobj_attribute hoge_attribute = + __ATTR_DATA(hoge, 0666, integer_show, integer_store, (long) 123); +static struct kobj_attribute piyo_attribute = + __ATTR_DATA(piyo, 0666, integer_show, integer_store, (long) 456); +static struct kobj_attribute fuga_attribute = + __ATTR_DATA(fuga, 0444, integer_show, NULL, (long) 789); /* * Create a group of attributes so that we can create and destory them all @@ -86,6 +115,9 @@ static struct attribute *attrs[] = { &foo_attribute.attr, &baz_attribute.attr, &bar_attribute.attr, + &hoge_attribute.attr, + &piyo_attribute.attr, + &fuga_attribute.attr, NULL, /* need to NULL terminate the list of attributes */ }; -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-02-25 6:06 [PATCH 0/3] exporting capability name/code pairs (final#2) Kohei KaiGai ` (2 preceding siblings ...) 2008-02-25 6:10 ` [PATCH 3/3] a new example to use kobject/kobj_attribute (final#2) Kohei KaiGai @ 2008-04-22 11:12 ` KaiGai Kohei 2008-04-22 11:17 ` [PATCH 1/3] add a private data field within kobj_attribute structure KaiGai Kohei ` (4 more replies) 3 siblings, 5 replies; 32+ messages in thread From: KaiGai Kohei @ 2008-04-22 11:12 UTC (permalink / raw) To: greg, morgan, serue, chrisw; +Cc: linux-security-module, linux-kernel The following three patches enables to export code/name pairs of capabilities the running kernel supports, and add a documentation and samples to use this feature. It was too late for 2.6.25 merge window, so I submit them again for the next development cycle. [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can refer this information to identify what entry is accessed. It makes easier to share a single method implementation with several similar entries, like ones to export the list of capabilities the running kernel supports. [PATCH 2/3] exporting capability name/code pairs This patch enables to export code/name pairs of capabilities the running kernel supported. A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN at 2.6.25. However, we have no interface to disclose what capabilities are supported on the running kernel. Thus, we have to maintain libcap version in appropriate one synchronously. This patch enables libcap to collect the list of capabilities at run time, and provide them for users. It helps to improve portability of library. It exports these information as regular files under /sys/kernel/capability. The numeric node exports its name, the symbolic node exports its code. [PATCH 3/3] a new example to use kobject/kobj_attribute This patch can provide a new exmple to use kobject and attribute. The _show() and _store() method can refer/store the private data field of kobj_attribute structure to know what entries are accessed by users. It will make easier to share a single _show()/_store() method with several entries. -------------- Example of execution: [kaigai@saba ~]$ uname -r 2.6.25.capnames [kaigai@saba ~]$ ls -R /sys/kernel/capability/ /sys/kernel/capability/: codes names version /sys/kernel/capability/codes: 0 10 12 14 16 18 2 21 23 25 27 29 30 32 4 6 8 1 11 13 15 17 19 20 22 24 26 28 3 31 33 5 7 9 /sys/kernel/capability/names: cap_audit_control cap_kill cap_net_raw cap_sys_nice cap_audit_write cap_lease cap_setfcap cap_sys_pacct cap_chown cap_linux_immutable cap_setgid cap_sys_ptrace cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio cap_dac_read_search cap_mac_override cap_setuid cap_sys_resource cap_fowner cap_mknod cap_sys_admin cap_sys_time cap_fsetid cap_net_admin cap_sys_boot cap_sys_tty_config cap_ipc_lock cap_net_bind_service cap_sys_chroot cap_ipc_owner cap_net_broadcast cap_sys_module [kaigai@saba ~]$ cat /sys/kernel/capability/names/cap_sys_pacct 20 [kaigai@saba ~]$ cat /sys/kernel/capability/codes/16 cap_sys_module [kaigai@saba ~]$ -------------- Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 1/3] add a private data field within kobj_attribute structure. 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei @ 2008-04-22 11:17 ` KaiGai Kohei 2008-04-22 11:18 ` [PATCH 2/3] exporting capability name/code pairs KaiGai Kohei ` (3 subsequent siblings) 4 siblings, 0 replies; 32+ messages in thread From: KaiGai Kohei @ 2008-04-22 11:17 UTC (permalink / raw) To: greg, morgan, serue, chrisw; +Cc: linux-security-module, linux-kernel [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can refer this information to identify what entry is accessed. It makes easier to share a single method implementation with several similar entries, like ones to export the list of capabilities the running kernel supports. Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> -- Documentation/kobject.txt | 6 ++++++ include/linux/kobject.h | 1 + include/linux/sysfs.h | 7 +++++++ 3 files changed, 14 insertions(+), 0 deletions(-) diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt index bf3256e..efa5d71 100644 --- a/Documentation/kobject.txt +++ b/Documentation/kobject.txt @@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created with the kobject_create_and_add(), can be of type kobj_attribute, so no special custom attribute is needed to be created. +The simple kobj_attribute is prototyped at include/linux/kobject.h, and can +contain your own show()/store() method and private data. +When an attribute is accessed, these methods are invoked with kobject, +kobj_attribute and read/write buffer. The method can refer the private data +via given kobj_attribute, to show/store itself in the text representation. + See the example module, samples/kobject/kobject-example.c for an implementation of a simple kobject and attributes. diff --git a/include/linux/kobject.h b/include/linux/kobject.h index caa3f41..57d5bf1 100644 --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -130,6 +130,7 @@ struct kobj_attribute { char *buf); ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count); + void *data; /* a private field */ }; extern struct sysfs_ops kobj_sysfs_ops; diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h index 03378e3..c43b0f5 100644 --- a/include/linux/sysfs.h +++ b/include/linux/sysfs.h @@ -50,6 +50,13 @@ struct attribute_group { .store = _store, \ } +#define __ATTR_DATA(_name,_mode,_show,_store,_data) { \ + .attr = {.name = __stringify(_name), .mode = _mode }, \ + .show = _show, \ + .store = _store, \ + .data = (void *)(_data), \ +} + #define __ATTR_RO(_name) { \ .attr = { .name = __stringify(_name), .mode = 0444 }, \ .show = _name##_show, \ -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH 2/3] exporting capability name/code pairs 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei 2008-04-22 11:17 ` [PATCH 1/3] add a private data field within kobj_attribute structure KaiGai Kohei @ 2008-04-22 11:18 ` KaiGai Kohei 2008-04-22 11:18 ` [PATCH 3/3] a new example to use kobject/kobj_attribute KaiGai Kohei ` (2 subsequent siblings) 4 siblings, 0 replies; 32+ messages in thread From: KaiGai Kohei @ 2008-04-22 11:18 UTC (permalink / raw) To: greg, morgan, serue, chrisw; +Cc: linux-security-module, linux-kernel [PATCH 2/3] exporting capability name/code pairs This patch enables to export code/name pairs of capabilities the running kernel supported. A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN at 2.6.25. However, we have no interface to disclose what capabilities are supported on the running kernel. Thus, we have to maintain libcap version in appropriate one synchronously. This patch enables libcap to collect the list of capabilities at run time, and provide them for users. It helps to improve portability of library. It exports these information as regular files under /sys/kernel/capability. The numeric node exports its name, the symbolic node exports its code. Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> -- scripts/mkcapnames.sh | 44 ++++++++++++++++++++++ security/Makefile | 9 ++++ security/commoncap.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 152 insertions(+), 0 deletions(-) diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh index e69de29..5d36d52 100644 --- a/scripts/mkcapnames.sh +++ b/scripts/mkcapnames.sh @@ -0,0 +1,44 @@ +#!/bin/sh + +# +# generate a cap_names.h file from include/linux/capability.h +# + +CAPHEAD="`dirname $0`/../include/linux/capability.h" +REGEXP='^#define CAP_[A-Z_]+[ ]+[0-9]+$' +NUMCAP=`cat "$CAPHEAD" | egrep -c "$REGEXP"` + +echo '#ifndef CAP_NAMES_H' +echo '#define CAP_NAMES_H' +echo +echo '/*' +echo ' * Do NOT edit this file directly.' +echo ' * This file is generated from include/linux/capability.h automatically' +echo ' */' +echo +echo '#if !defined(SYSFS_CAP_NAME_ENTRY) || !defined(SYSFS_CAP_CODE_ENTRY)' +echo '#error cap_names.h should be included from security/capability.c' +echo '#else' +echo "#if $NUMCAP != CAP_LAST_CAP + 1" +echo '#error mkcapnames.sh cannot collect capabilities correctly' +echo '#else' +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("SYSFS_CAP_NAME_ENTRY(%s,%s);\n", tolower($2), $2); }' +echo +echo 'static struct attribute *capability_name_attrs[] = {' +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("\t&%s_name_attr.attr,\n", tolower($2)); } END { print "\tNULL," }' +echo '};' + +echo +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("SYSFS_CAP_CODE_ENTRY(%s,%s);\n", tolower($2), $2); }' +echo +echo 'static struct attribute *capability_code_attrs[] = {' +cat "$CAPHEAD" | egrep "$REGEXP" \ + | awk '{ printf("\t&%s_code_attr.attr,\n", tolower($2)); } END { print "\tNULL," }' +echo '};' + +echo '#endif' +echo '#endif' +echo '#endif' diff --git a/security/Makefile b/security/Makefile index 9e8b025..4093e3e 100644 --- a/security/Makefile +++ b/security/Makefile @@ -18,3 +18,12 @@ obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o obj-$(CONFIG_SECURITY_SMACK) += commoncap.o smack/built-in.o obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o + +# cap_names.h contains the code/name pair of capabilities. +# It is generated using include/linux/capability.h automatically. +$(obj)/commoncap.o: $(obj)/cap_names.h +quiet_cmd_cap_names = CAPS $@ + cmd_cap_names = /bin/sh $(srctree)/scripts/mkcapnames.sh > $@ +targets += cap_names.h +$(obj)/cap_names.h: $(srctree)/scripts/mkcapnames.sh $(srctree)/include/linux/capability.h FORCE + $(call if_changed,cap_names) diff --git a/security/commoncap.c b/security/commoncap.c index 8529057..d2f8d40 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -24,6 +24,8 @@ #include <linux/hugetlb.h> #include <linux/mount.h> #include <linux/sched.h> +#include <linux/kobject.h> +#include <linux/sysfs.h> /* Global security state */ @@ -597,3 +599,100 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages) return __vm_enough_memory(mm, pages, cap_sys_admin); } +/* + * Export the list of capabilities on /sys/kernel/capability + */ +static struct kobject *capability_kobj; + +static ssize_t capability_name_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buffer) +{ + /* It returns numerical representation of capability. */ + return scnprintf(buffer, PAGE_SIZE, "%ld\n", (long) attr->data); +} + +static ssize_t capability_code_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buffer) +{ + /* It returns symbolic representation of capability. */ + return scnprintf(buffer, PAGE_SIZE, "%s\n", (char *) attr->data); +} + +static ssize_t capability_version_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buffer) +{ + return scnprintf(buffer, PAGE_SIZE, "0x%08x\n", + _LINUX_CAPABILITY_VERSION); +} + +#define SYSFS_CAP_NAME_ENTRY(_name,_code) \ + static struct kobj_attribute _name##_name_attr = \ + __ATTR_DATA(_name, 0444, capability_name_show, NULL, (long)(_code)) + +#define SYSFS_CAP_CODE_ENTRY(_name,_code) \ + static struct kobj_attribute _name##_code_attr = \ + __ATTR_DATA(_code, 0444, capability_code_show, NULL, __stringify(_name)) + +/* + * capability_attrs[] is generated automatically by scripts/mkcapnames.sh + * This script parses include/linux/capability.h + */ +#include "cap_names.h" + +static struct attribute_group capability_name_attr_group = { + .name = "names", + .attrs = capability_name_attrs, +}; + +static struct attribute_group capability_code_attr_group = { + .name = "codes", + .attrs = capability_code_attrs, +}; + +static struct kobj_attribute cap_version_attr = + __ATTR(version, 0444, capability_version_show, NULL); + +static int __init capability_export_names(void) +{ + int rc = -ENOMEM; + + /* make /sys/kernel/capability */ + capability_kobj = kobject_create_and_add("capability", kernel_kobj); + if (!capability_kobj) + goto error0; + + /* make /sys/kernel/capability/names */ + rc = sysfs_create_group(capability_kobj, + &capability_name_attr_group); + if (rc) + goto error1; + + /* make /sys/kernel/capability/codes */ + rc = sysfs_create_group(capability_kobj, + &capability_code_attr_group); + if (rc) + goto error2; + + /* make /sys/kernel/capability/version */ + rc = sysfs_create_file(capability_kobj, + &cap_version_attr.attr); + if (rc) + goto error3; + + return 0; + +error3: + sysfs_remove_group(capability_kobj, &capability_code_attr_group); +error2: + sysfs_remove_group(capability_kobj, &capability_name_attr_group); +error1: + kobject_put(capability_kobj); +error0: + printk(KERN_ERR "Unable to export capabilities\n"); + + return rc; +} +__initcall(capability_export_names); -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH 3/3] a new example to use kobject/kobj_attribute 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei 2008-04-22 11:17 ` [PATCH 1/3] add a private data field within kobj_attribute structure KaiGai Kohei 2008-04-22 11:18 ` [PATCH 2/3] exporting capability name/code pairs KaiGai Kohei @ 2008-04-22 11:18 ` KaiGai Kohei 2008-04-22 19:29 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) Alexey Dobriyan 2008-04-23 5:37 ` Chris Wright 4 siblings, 0 replies; 32+ messages in thread From: KaiGai Kohei @ 2008-04-22 11:18 UTC (permalink / raw) To: greg, morgan, serue, chrisw; +Cc: linux-security-module, linux-kernel [PATCH 3/3] a new example to use kobject/kobj_attribute This patch can provide a new exmple to use kobject and attribute. The _show() and _store() method can refer/store the private data field of kobj_attribute structure to know what entries are accessed by users. It will make easier to share a single _show()/_store() method with several entries. Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> -- samples/kobject/kobject-example.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/samples/kobject/kobject-example.c b/samples/kobject/kobject-example.c index 08d0d3f..5486a14 100644 --- a/samples/kobject/kobject-example.c +++ b/samples/kobject/kobject-example.c @@ -77,6 +77,35 @@ static struct kobj_attribute baz_attribute = static struct kobj_attribute bar_attribute = __ATTR(bar, 0666, b_show, b_store); +/* + * You can store a private data within 'data' field of kobj_attribute. + * It enables to share a single _show() or _store() method with several + * entries. + */ +static ssize_t integer_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buf) +{ + return scnprintf(buf, PAGE_SIZE, "%ld\n", (long) attr->data); +} + +static ssize_t integer_store(struct kobject *kobj, + struct kobj_attribute *attr, + const char *buf, size_t count) +{ + long code; + + sscanf(buf, "%ld", &code); + attr->data = (void *) code; + return count; +} + +static struct kobj_attribute hoge_attribute = + __ATTR_DATA(hoge, 0666, integer_show, integer_store, (long) 123); +static struct kobj_attribute piyo_attribute = + __ATTR_DATA(piyo, 0666, integer_show, integer_store, (long) 456); +static struct kobj_attribute fuga_attribute = + __ATTR_DATA(fuga, 0444, integer_show, NULL, (long) 789); /* * Create a group of attributes so that we can create and destory them all @@ -86,6 +115,9 @@ static struct attribute *attrs[] = { &foo_attribute.attr, &baz_attribute.attr, &bar_attribute.attr, + &hoge_attribute.attr, + &piyo_attribute.attr, + &fuga_attribute.attr, NULL, /* need to NULL terminate the list of attributes */ }; -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei ` (2 preceding siblings ...) 2008-04-22 11:18 ` [PATCH 3/3] a new example to use kobject/kobj_attribute KaiGai Kohei @ 2008-04-22 19:29 ` Alexey Dobriyan 2008-04-23 0:38 ` KaiGai Kohei 2008-04-23 5:37 ` Chris Wright 4 siblings, 1 reply; 32+ messages in thread From: Alexey Dobriyan @ 2008-04-22 19:29 UTC (permalink / raw) To: KaiGai Kohei Cc: greg, morgan, serue, chrisw, linux-security-module, linux-kernel On Tue, Apr 22, 2008 at 08:12:15PM +0900, KaiGai Kohei wrote: > $ ls -R /sys/kernel/capability/ > /sys/kernel/capability/: > codes names version > > /sys/kernel/capability/codes: > 0 10 12 14 16 18 2 21 23 25 27 29 30 32 4 6 8 > 1 11 13 15 17 19 20 22 24 26 28 3 31 33 5 7 9 > > /sys/kernel/capability/names: > cap_audit_control cap_kill cap_net_raw cap_sys_nice > cap_audit_write cap_lease cap_setfcap cap_sys_pacct > cap_chown cap_linux_immutable cap_setgid cap_sys_ptrace > cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio > cap_dac_read_search cap_mac_override cap_setuid cap_sys_resource > cap_fowner cap_mknod cap_sys_admin cap_sys_time > cap_fsetid cap_net_admin cap_sys_boot cap_sys_tty_config > cap_ipc_lock cap_net_bind_service cap_sys_chroot > cap_ipc_owner cap_net_broadcast cap_sys_module > $ cat /sys/kernel/capability/names/cap_sys_pacct > 20 > $ cat /sys/kernel/capability/codes/16 > cap_sys_module This is amazing amount of bloat for such conceptually simple feature! Below is /proc/capabilities , a) without all memory eaten by sysfs files and directories, generated on the fly b) with capability names matching the ones in manpages c) nicely formatted e) with whole-whooping 2 lines of protection from fool (including helpful directions) Proposed regexp of course will incorrectly match someday If this file will be used often, I can even make whole its content become generated at compile time and then put into buffers with 1 (one) seq_puts()! Alexey "0 CAP_CHOWN 1 CAP_DAC_OVERRIDE 2 CAP_DAC_READ_SEARCH 3 CAP_FOWNER 4 CAP_FSETID 5 CAP_KILL 6 CAP_SETGID 7 CAP_SETUID 8 CAP_SETPCAP 9 CAP_LINUX_IMMUTABLE 10 CAP_NET_BIND_SERVICE 11 CAP_NET_BROADCAST 12 CAP_NET_ADMIN 13 CAP_NET_RAW 14 CAP_IPC_LOCK 15 CAP_IPC_OWNER 16 CAP_SYS_MODULE 17 CAP_SYS_RAWIO 18 CAP_SYS_CHROOT 19 CAP_SYS_PTRACE 20 CAP_SYS_PACCT 21 CAP_SYS_ADMIN 22 CAP_SYS_BOOT 23 CAP_SYS_NICE 24 CAP_SYS_RESOURCE 25 CAP_SYS_TIME 26 CAP_SYS_TTY_CONFIG 27 CAP_MKNOD 28 CAP_LEASE 29 CAP_AUDIT_WRITE 30 CAP_AUDIT_CONTROL 31 CAP_SETFCAP 32 CAP_MAC_OVERRIDE 33 CAP_MAC_ADMIN" Dobriyan --- a/security/commoncap.c +++ b/security/commoncap.c @@ -19,6 +19,8 @@ #include <linux/swap.h> #include <linux/skbuff.h> #include <linux/netlink.h> +#include <linux/proc_fs.h> +#include <linux/seq_file.h> #include <linux/ptrace.h> #include <linux/xattr.h> #include <linux/hugetlb.h> @@ -597,3 +599,81 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages) return __vm_enough_memory(mm, pages, cap_sys_admin); } +#ifdef CONFIG_PROC_FS +static const struct { + int val; + const char *str; +} proc_cap[] = { +#define _(cap) { .val = cap, .str = #cap } + _(CAP_CHOWN), + _(CAP_DAC_OVERRIDE), + _(CAP_DAC_READ_SEARCH), + _(CAP_FOWNER), + _(CAP_FSETID), + _(CAP_KILL), + _(CAP_SETGID), + _(CAP_SETUID), + _(CAP_SETPCAP), + _(CAP_LINUX_IMMUTABLE), + _(CAP_NET_BIND_SERVICE), + _(CAP_NET_BROADCAST), + _(CAP_NET_ADMIN), + _(CAP_NET_RAW), + _(CAP_IPC_LOCK), + _(CAP_IPC_OWNER), + _(CAP_SYS_MODULE), + _(CAP_SYS_RAWIO), + _(CAP_SYS_CHROOT), + _(CAP_SYS_PTRACE), + _(CAP_SYS_PACCT), + _(CAP_SYS_ADMIN), + _(CAP_SYS_BOOT), + _(CAP_SYS_NICE), + _(CAP_SYS_RESOURCE), + _(CAP_SYS_TIME), + _(CAP_SYS_TTY_CONFIG), + _(CAP_MKNOD), + _(CAP_LEASE), + _(CAP_AUDIT_WRITE), + _(CAP_AUDIT_CONTROL), + _(CAP_SETFCAP), + _(CAP_MAC_OVERRIDE), + _(CAP_MAC_ADMIN), +#undef _ +}; + +static int proc_capabilities_show(struct seq_file *m, void *v) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(proc_cap); i++) + seq_printf(m, "%d\t%s\n", proc_cap[i].val, proc_cap[i].str); + return 0; +} + +static int proc_capabilities_open(struct inode *inode, struct file *file) +{ + return single_open(file, proc_capabilities_show, NULL); +} + +static const struct file_operations capabilities_proc_fops = { + .owner = THIS_MODULE, + .open = proc_capabilities_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +static int __init commoncap_init(void) +{ + struct proc_dir_entry *pde; + + pde = proc_create("capabilities", 0, NULL, &capabilities_proc_fops); + if (!pde) + return -ENOMEM; + /* Forgot to add new capability to proc_cap array? */ + BUILD_BUG_ON(ARRAY_SIZE(proc_cap) != CAP_LAST_CAP + 1); + return 0; +} +module_init(commoncap_init); +#endif ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-22 19:29 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) Alexey Dobriyan @ 2008-04-23 0:38 ` KaiGai Kohei 2008-04-23 7:03 ` Alexey Dobriyan 0 siblings, 1 reply; 32+ messages in thread From: KaiGai Kohei @ 2008-04-23 0:38 UTC (permalink / raw) To: Alexey Dobriyan Cc: greg, morgan, serue, chrisw, linux-security-module, linux-kernel Alexey Dobriyan wrote: > On Tue, Apr 22, 2008 at 08:12:15PM +0900, KaiGai Kohei wrote: >> $ ls -R /sys/kernel/capability/ >> /sys/kernel/capability/: >> codes names version >> >> /sys/kernel/capability/codes: >> 0 10 12 14 16 18 2 21 23 25 27 29 30 32 4 6 8 >> 1 11 13 15 17 19 20 22 24 26 28 3 31 33 5 7 9 >> >> /sys/kernel/capability/names: >> cap_audit_control cap_kill cap_net_raw cap_sys_nice >> cap_audit_write cap_lease cap_setfcap cap_sys_pacct >> cap_chown cap_linux_immutable cap_setgid cap_sys_ptrace >> cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio >> cap_dac_read_search cap_mac_override cap_setuid cap_sys_resource >> cap_fowner cap_mknod cap_sys_admin cap_sys_time >> cap_fsetid cap_net_admin cap_sys_boot cap_sys_tty_config >> cap_ipc_lock cap_net_bind_service cap_sys_chroot >> cap_ipc_owner cap_net_broadcast cap_sys_module >> $ cat /sys/kernel/capability/names/cap_sys_pacct >> 20 >> $ cat /sys/kernel/capability/codes/16 >> cap_sys_module > > This is amazing amount of bloat for such conceptually simple feature! > > Below is /proc/capabilities , > a) without all memory eaten by sysfs files and directories, > generated on the fly > b) with capability names matching the ones in manpages > c) nicely formatted > e) with whole-whooping 2 lines of protection from fool > (including helpful directions) > Proposed regexp of course will incorrectly match someday > > If this file will be used often, I can even make whole its content > become generated at compile time and then put into buffers > with 1 (one) seq_puts()! I had suggested a similar idea previously, but it could not be supported because it requires to scan whole of /proc/capabilities at first. Using sysfs enables to translate them without seeking, as Andrew Morgan said. > Alexey "0 CAP_CHOWN > 1 CAP_DAC_OVERRIDE > 2 CAP_DAC_READ_SEARCH > 3 CAP_FOWNER > 4 CAP_FSETID > 5 CAP_KILL > 6 CAP_SETGID > 7 CAP_SETUID > 8 CAP_SETPCAP > 9 CAP_LINUX_IMMUTABLE > 10 CAP_NET_BIND_SERVICE > 11 CAP_NET_BROADCAST > 12 CAP_NET_ADMIN > 13 CAP_NET_RAW > 14 CAP_IPC_LOCK > 15 CAP_IPC_OWNER > 16 CAP_SYS_MODULE > 17 CAP_SYS_RAWIO > 18 CAP_SYS_CHROOT > 19 CAP_SYS_PTRACE > 20 CAP_SYS_PACCT > 21 CAP_SYS_ADMIN > 22 CAP_SYS_BOOT > 23 CAP_SYS_NICE > 24 CAP_SYS_RESOURCE > 25 CAP_SYS_TIME > 26 CAP_SYS_TTY_CONFIG > 27 CAP_MKNOD > 28 CAP_LEASE > 29 CAP_AUDIT_WRITE > 30 CAP_AUDIT_CONTROL > 31 CAP_SETFCAP > 32 CAP_MAC_OVERRIDE > 33 CAP_MAC_ADMIN" Dobriyan > > --- a/security/commoncap.c > +++ b/security/commoncap.c > @@ -19,6 +19,8 @@ > #include <linux/swap.h> > #include <linux/skbuff.h> > #include <linux/netlink.h> > +#include <linux/proc_fs.h> > +#include <linux/seq_file.h> > #include <linux/ptrace.h> > #include <linux/xattr.h> > #include <linux/hugetlb.h> > @@ -597,3 +599,81 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages) > return __vm_enough_memory(mm, pages, cap_sys_admin); > } > > +#ifdef CONFIG_PROC_FS > +static const struct { > + int val; > + const char *str; > +} proc_cap[] = { > +#define _(cap) { .val = cap, .str = #cap } > + _(CAP_CHOWN), > + _(CAP_DAC_OVERRIDE), > + _(CAP_DAC_READ_SEARCH), > + _(CAP_FOWNER), > + _(CAP_FSETID), > + _(CAP_KILL), > + _(CAP_SETGID), > + _(CAP_SETUID), > + _(CAP_SETPCAP), > + _(CAP_LINUX_IMMUTABLE), > + _(CAP_NET_BIND_SERVICE), > + _(CAP_NET_BROADCAST), > + _(CAP_NET_ADMIN), > + _(CAP_NET_RAW), > + _(CAP_IPC_LOCK), > + _(CAP_IPC_OWNER), > + _(CAP_SYS_MODULE), > + _(CAP_SYS_RAWIO), > + _(CAP_SYS_CHROOT), > + _(CAP_SYS_PTRACE), > + _(CAP_SYS_PACCT), > + _(CAP_SYS_ADMIN), > + _(CAP_SYS_BOOT), > + _(CAP_SYS_NICE), > + _(CAP_SYS_RESOURCE), > + _(CAP_SYS_TIME), > + _(CAP_SYS_TTY_CONFIG), > + _(CAP_MKNOD), > + _(CAP_LEASE), > + _(CAP_AUDIT_WRITE), > + _(CAP_AUDIT_CONTROL), > + _(CAP_SETFCAP), > + _(CAP_MAC_OVERRIDE), > + _(CAP_MAC_ADMIN), > +#undef _ It should be generated automatically. and, where is the "version" information? > +}; > + > +static int proc_capabilities_show(struct seq_file *m, void *v) > +{ > + int i; > + > + for (i = 0; i < ARRAY_SIZE(proc_cap); i++) > + seq_printf(m, "%d\t%s\n", proc_cap[i].val, proc_cap[i].str); > + return 0; > +} > + > +static int proc_capabilities_open(struct inode *inode, struct file *file) > +{ > + return single_open(file, proc_capabilities_show, NULL); > +} > + > +static const struct file_operations capabilities_proc_fops = { > + .owner = THIS_MODULE, > + .open = proc_capabilities_open, > + .read = seq_read, > + .llseek = seq_lseek, > + .release = single_release, > +}; > + > +static int __init commoncap_init(void) > +{ > + struct proc_dir_entry *pde; > + > + pde = proc_create("capabilities", 0, NULL, &capabilities_proc_fops); > + if (!pde) > + return -ENOMEM; > + /* Forgot to add new capability to proc_cap array? */ > + BUILD_BUG_ON(ARRAY_SIZE(proc_cap) != CAP_LAST_CAP + 1); > + return 0; > +} > +module_init(commoncap_init); > +#endif > > -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-23 0:38 ` KaiGai Kohei @ 2008-04-23 7:03 ` Alexey Dobriyan 2008-04-23 7:37 ` KaiGai Kohei 0 siblings, 1 reply; 32+ messages in thread From: Alexey Dobriyan @ 2008-04-23 7:03 UTC (permalink / raw) To: KaiGai Kohei Cc: greg, morgan, serue, chrisw, linux-security-module, linux-kernel On Wed, Apr 23, 2008 at 09:38:31AM +0900, KaiGai Kohei wrote: > Alexey Dobriyan wrote: >> On Tue, Apr 22, 2008 at 08:12:15PM +0900, KaiGai Kohei wrote: >>> $ ls -R /sys/kernel/capability/ >>> /sys/kernel/capability/: >>> codes names version >>> >>> /sys/kernel/capability/codes: >>> 0 10 12 14 16 18 2 21 23 25 27 29 30 32 4 6 8 >>> 1 11 13 15 17 19 20 22 24 26 28 3 31 33 5 7 9 >>> >>> /sys/kernel/capability/names: >>> cap_audit_control cap_kill cap_net_raw cap_sys_nice >>> cap_audit_write cap_lease cap_setfcap cap_sys_pacct >>> cap_chown cap_linux_immutable cap_setgid cap_sys_ptrace >>> cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio >>> cap_dac_read_search cap_mac_override cap_setuid >>> cap_sys_resource >>> cap_fowner cap_mknod cap_sys_admin cap_sys_time >>> cap_fsetid cap_net_admin cap_sys_boot >>> cap_sys_tty_config >>> cap_ipc_lock cap_net_bind_service cap_sys_chroot >>> cap_ipc_owner cap_net_broadcast cap_sys_module >>> $ cat /sys/kernel/capability/names/cap_sys_pacct >>> 20 >>> $ cat /sys/kernel/capability/codes/16 >>> cap_sys_module >> This is amazing amount of bloat for such conceptually simple feature! >> Below is /proc/capabilities , >> a) without all memory eaten by sysfs files and directories, >> generated on the fly >> b) with capability names matching the ones in manpages >> c) nicely formatted >> e) with whole-whooping 2 lines of protection from fool >> (including helpful directions) >> Proposed regexp of course will incorrectly match someday >> If this file will be used often, I can even make whole its content >> become generated at compile time and then put into buffers >> with 1 (one) seq_puts()! > > I had suggested a similar idea previously, but it could not be supported > because it requires to scan whole of /proc/capabilities at first. You claim that libcap people can't or don't want to parse such file? 0 CAP_CHOWN 1 CAP_DAC_OVERRIDE 2 CAP_DAC_READ_SEARCH 3 CAP_FOWNER 4 CAP_FSETID 5 CAP_KILL 6 CAP_SETGID 7 CAP_SETUID 8 CAP_SETPCAP 9 CAP_LINUX_IMMUTABLE 10 CAP_NET_BIND_SERVICE 11 CAP_NET_BROADCAST 12 CAP_NET_ADMIN 13 CAP_NET_RAW 14 CAP_IPC_LOCK 15 CAP_IPC_OWNER 16 CAP_SYS_MODULE 17 CAP_SYS_RAWIO 18 CAP_SYS_CHROOT 19 CAP_SYS_PTRACE 20 CAP_SYS_PACCT 21 CAP_SYS_ADMIN 22 CAP_SYS_BOOT 23 CAP_SYS_NICE 24 CAP_SYS_RESOURCE 25 CAP_SYS_TIME 26 CAP_SYS_TTY_CONFIG 27 CAP_MKNOD 28 CAP_LEASE 29 CAP_AUDIT_WRITE 30 CAP_AUDIT_CONTROL 31 CAP_SETFCAP 32 CAP_MAC_OVERRIDE 33 CAP_MAC_ADMIN That's what you claim? Do I undestand you correctly? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-23 7:03 ` Alexey Dobriyan @ 2008-04-23 7:37 ` KaiGai Kohei 2008-05-13 22:12 ` Alexey Dobriyan 0 siblings, 1 reply; 32+ messages in thread From: KaiGai Kohei @ 2008-04-23 7:37 UTC (permalink / raw) To: Alexey Dobriyan Cc: greg, morgan, serue, chrisw, linux-security-module, linux-kernel Alexey Dobriyan wrote: > On Wed, Apr 23, 2008 at 09:38:31AM +0900, KaiGai Kohei wrote: >> Alexey Dobriyan wrote: >>> On Tue, Apr 22, 2008 at 08:12:15PM +0900, KaiGai Kohei wrote: >>>> $ ls -R /sys/kernel/capability/ >>>> /sys/kernel/capability/: >>>> codes names version >>>> >>>> /sys/kernel/capability/codes: >>>> 0 10 12 14 16 18 2 21 23 25 27 29 30 32 4 6 8 >>>> 1 11 13 15 17 19 20 22 24 26 28 3 31 33 5 7 9 >>>> >>>> /sys/kernel/capability/names: >>>> cap_audit_control cap_kill cap_net_raw cap_sys_nice >>>> cap_audit_write cap_lease cap_setfcap cap_sys_pacct >>>> cap_chown cap_linux_immutable cap_setgid cap_sys_ptrace >>>> cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio >>>> cap_dac_read_search cap_mac_override cap_setuid >>>> cap_sys_resource >>>> cap_fowner cap_mknod cap_sys_admin cap_sys_time >>>> cap_fsetid cap_net_admin cap_sys_boot >>>> cap_sys_tty_config >>>> cap_ipc_lock cap_net_bind_service cap_sys_chroot >>>> cap_ipc_owner cap_net_broadcast cap_sys_module >>>> $ cat /sys/kernel/capability/names/cap_sys_pacct >>>> 20 >>>> $ cat /sys/kernel/capability/codes/16 >>>> cap_sys_module >>> This is amazing amount of bloat for such conceptually simple feature! >>> Below is /proc/capabilities , >>> a) without all memory eaten by sysfs files and directories, >>> generated on the fly >>> b) with capability names matching the ones in manpages >>> c) nicely formatted >>> e) with whole-whooping 2 lines of protection from fool >>> (including helpful directions) >>> Proposed regexp of course will incorrectly match someday >>> If this file will be used often, I can even make whole its content >>> become generated at compile time and then put into buffers >>> with 1 (one) seq_puts()! >> I had suggested a similar idea previously, but it could not be supported >> because it requires to scan whole of /proc/capabilities at first. > > You claim that libcap people can't or don't want to parse such file? Yes, In the previous discussion, it was undesirable idea to parse a file to obtain a new/unknown capability name/code pair, because it tends to have bigger number and appears at the tail. (If my brain memories it correctly.) > 0 CAP_CHOWN > 1 CAP_DAC_OVERRIDE > 2 CAP_DAC_READ_SEARCH > 3 CAP_FOWNER > 4 CAP_FSETID > 5 CAP_KILL > 6 CAP_SETGID > 7 CAP_SETUID > 8 CAP_SETPCAP > 9 CAP_LINUX_IMMUTABLE > 10 CAP_NET_BIND_SERVICE > 11 CAP_NET_BROADCAST > 12 CAP_NET_ADMIN > 13 CAP_NET_RAW > 14 CAP_IPC_LOCK > 15 CAP_IPC_OWNER > 16 CAP_SYS_MODULE > 17 CAP_SYS_RAWIO > 18 CAP_SYS_CHROOT > 19 CAP_SYS_PTRACE > 20 CAP_SYS_PACCT > 21 CAP_SYS_ADMIN > 22 CAP_SYS_BOOT > 23 CAP_SYS_NICE > 24 CAP_SYS_RESOURCE > 25 CAP_SYS_TIME > 26 CAP_SYS_TTY_CONFIG > 27 CAP_MKNOD > 28 CAP_LEASE > 29 CAP_AUDIT_WRITE > 30 CAP_AUDIT_CONTROL > 31 CAP_SETFCAP > 32 CAP_MAC_OVERRIDE > 33 CAP_MAC_ADMIN > > That's what you claim? Do I undestand you correctly? Yes, but I don't *oppose* your approach. :) BTW, I think "version" info should be included as follows: 0x20071026 vesion 0 cap_chown 1 cap_dac_override : : Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-23 7:37 ` KaiGai Kohei @ 2008-05-13 22:12 ` Alexey Dobriyan 2008-05-14 0:34 ` KaiGai Kohei 0 siblings, 1 reply; 32+ messages in thread From: Alexey Dobriyan @ 2008-05-13 22:12 UTC (permalink / raw) To: KaiGai Kohei Cc: greg, morgan, serue, chrisw, linux-security-module, linux-kernel >> You claim that libcap people can't or don't want to parse such file? > > Yes, > In the previous discussion, it was undesirable idea to parse a file > to obtain a new/unknown capability name/code pair, because it tends > to have bigger number and appears at the tail. > (If my brain memories it correctly.) > >> 0 CAP_CHOWN >> 1 CAP_DAC_OVERRIDE >> 2 CAP_DAC_READ_SEARCH >> 3 CAP_FOWNER >> 4 CAP_FSETID >> 5 CAP_KILL >> 6 CAP_SETGID >> 7 CAP_SETUID >> 8 CAP_SETPCAP >> 9 CAP_LINUX_IMMUTABLE >> 10 CAP_NET_BIND_SERVICE >> 11 CAP_NET_BROADCAST >> 12 CAP_NET_ADMIN >> 13 CAP_NET_RAW >> 14 CAP_IPC_LOCK >> 15 CAP_IPC_OWNER >> 16 CAP_SYS_MODULE >> 17 CAP_SYS_RAWIO >> 18 CAP_SYS_CHROOT >> 19 CAP_SYS_PTRACE >> 20 CAP_SYS_PACCT >> 21 CAP_SYS_ADMIN >> 22 CAP_SYS_BOOT >> 23 CAP_SYS_NICE >> 24 CAP_SYS_RESOURCE >> 25 CAP_SYS_TIME >> 26 CAP_SYS_TTY_CONFIG >> 27 CAP_MKNOD >> 28 CAP_LEASE >> 29 CAP_AUDIT_WRITE >> 30 CAP_AUDIT_CONTROL >> 31 CAP_SETFCAP >> 32 CAP_MAC_OVERRIDE >> 33 CAP_MAC_ADMIN >> That's what you claim? Do I undestand you correctly? > > Yes, but I don't *oppose* your approach. :) > > BTW, I think "version" info should be included as follows: > 0x20071026 vesion > 0 cap_chown > 1 cap_dac_override > : : It shouldn't. You can do capget(42, ...);, get EINVAL and current version written back. Wrap this in libcap if needed. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-05-13 22:12 ` Alexey Dobriyan @ 2008-05-14 0:34 ` KaiGai Kohei 0 siblings, 0 replies; 32+ messages in thread From: KaiGai Kohei @ 2008-05-14 0:34 UTC (permalink / raw) To: Alexey Dobriyan Cc: greg, morgan, serue, chrisw, linux-security-module, linux-kernel Alexey Dobriyan wrote: >>> You claim that libcap people can't or don't want to parse such file? >> Yes, >> In the previous discussion, it was undesirable idea to parse a file >> to obtain a new/unknown capability name/code pair, because it tends >> to have bigger number and appears at the tail. >> (If my brain memories it correctly.) >> >>> 0 CAP_CHOWN >>> 1 CAP_DAC_OVERRIDE >>> 2 CAP_DAC_READ_SEARCH >>> 3 CAP_FOWNER >>> 4 CAP_FSETID >>> 5 CAP_KILL >>> 6 CAP_SETGID >>> 7 CAP_SETUID >>> 8 CAP_SETPCAP >>> 9 CAP_LINUX_IMMUTABLE >>> 10 CAP_NET_BIND_SERVICE >>> 11 CAP_NET_BROADCAST >>> 12 CAP_NET_ADMIN >>> 13 CAP_NET_RAW >>> 14 CAP_IPC_LOCK >>> 15 CAP_IPC_OWNER >>> 16 CAP_SYS_MODULE >>> 17 CAP_SYS_RAWIO >>> 18 CAP_SYS_CHROOT >>> 19 CAP_SYS_PTRACE >>> 20 CAP_SYS_PACCT >>> 21 CAP_SYS_ADMIN >>> 22 CAP_SYS_BOOT >>> 23 CAP_SYS_NICE >>> 24 CAP_SYS_RESOURCE >>> 25 CAP_SYS_TIME >>> 26 CAP_SYS_TTY_CONFIG >>> 27 CAP_MKNOD >>> 28 CAP_LEASE >>> 29 CAP_AUDIT_WRITE >>> 30 CAP_AUDIT_CONTROL >>> 31 CAP_SETFCAP >>> 32 CAP_MAC_OVERRIDE >>> 33 CAP_MAC_ADMIN >>> That's what you claim? Do I undestand you correctly? >> Yes, but I don't *oppose* your approach. :) >> >> BTW, I think "version" info should be included as follows: >> 0x20071026 vesion >> 0 cap_chown >> 1 cap_dac_override >> : : > > It shouldn't. You can do capget(42, ...);, get EINVAL and current > version written back. > > Wrap this in libcap if needed. libcap is the primary user of the facility to export capability name/code pairs. I think obviously libcap should wrap this version info and hide it from applications/users. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei ` (3 preceding siblings ...) 2008-04-22 19:29 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) Alexey Dobriyan @ 2008-04-23 5:37 ` Chris Wright 2008-04-23 7:15 ` KaiGai Kohei 4 siblings, 1 reply; 32+ messages in thread From: Chris Wright @ 2008-04-23 5:37 UTC (permalink / raw) To: KaiGai Kohei Cc: greg, morgan, serue, chrisw, linux-security-module, linux-kernel * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote: > [PATCH 2/3] exporting capability name/code pairs > > This patch enables to export code/name pairs of capabilities the running > kernel supported. > > A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN > at 2.6.25. However, we have no interface to disclose what capabilities > are supported on the running kernel. Thus, we have to maintain libcap > version in appropriate one synchronously. > > This patch enables libcap to collect the list of capabilities at run time, > and provide them for users. It helps to improve portability of library. > > It exports these information as regular files under /sys/kernel/capability. > The numeric node exports its name, the symbolic node exports its code. I do not understand why this is necessary. The capability bits are an ABI that shouldn't change in a non-backward compat way (i.e. only additions). We typically don't export strings <-> number conversions for constants. I know you've explained this a few times before, but it still seems to me like a userspace only problem. What can userspace do with a capability it does not know about? thanks, -chris ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-23 5:37 ` Chris Wright @ 2008-04-23 7:15 ` KaiGai Kohei 2008-05-14 0:36 ` KaiGai Kohei 0 siblings, 1 reply; 32+ messages in thread From: KaiGai Kohei @ 2008-04-23 7:15 UTC (permalink / raw) To: Chris Wright; +Cc: greg, morgan, serue, linux-security-module, linux-kernel Chris Wright wrote: > * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote: >> [PATCH 2/3] exporting capability name/code pairs >> >> This patch enables to export code/name pairs of capabilities the running >> kernel supported. >> >> A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN >> at 2.6.25. However, we have no interface to disclose what capabilities >> are supported on the running kernel. Thus, we have to maintain libcap >> version in appropriate one synchronously. >> >> This patch enables libcap to collect the list of capabilities at run time, >> and provide them for users. It helps to improve portability of library. >> >> It exports these information as regular files under /sys/kernel/capability. >> The numeric node exports its name, the symbolic node exports its code. > > I do not understand why this is necessary. The capability bits are an ABI > that shouldn't change in a non-backward compat way (i.e. only additions). > > We typically don't export strings <-> number conversions for constants. > I know you've explained this a few times before, but it still seems to me > like a userspace only problem. What can userspace do with a capability > it does not know about? When we run a userspace utility on the latest kernel, it has to be compiled with kernel-headers which have same capability set at least. If installed userspace utility does not support newly added capabilities, it requires users to rebuild their utilities when they update the kernel. Typically, kernel developer faces this kind of version mismatching. When they boots their kernel with new capabilities, it also requires to rebuild libcap. Then, they have to revert it, when they boots with normal kernel. If libcap can know what capabilities are supported on the running kernel automatically, it does not need users to rebuild libcap concurrently. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-04-23 7:15 ` KaiGai Kohei @ 2008-05-14 0:36 ` KaiGai Kohei 2008-05-14 0:52 ` Chris Wright 0 siblings, 1 reply; 32+ messages in thread From: KaiGai Kohei @ 2008-05-14 0:36 UTC (permalink / raw) To: Chris Wright; +Cc: greg, morgan, serue, linux-security-module, linux-kernel Chris, what is the status of the patch? KaiGai Kohei wrote: > Chris Wright wrote: >> * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote: >>> [PATCH 2/3] exporting capability name/code pairs >>> >>> This patch enables to export code/name pairs of capabilities the running >>> kernel supported. >>> >>> A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN >>> at 2.6.25. However, we have no interface to disclose what capabilities >>> are supported on the running kernel. Thus, we have to maintain libcap >>> version in appropriate one synchronously. >>> >>> This patch enables libcap to collect the list of capabilities at run >>> time, >>> and provide them for users. It helps to improve portability of library. >>> >>> It exports these information as regular files under >>> /sys/kernel/capability. >>> The numeric node exports its name, the symbolic node exports its code. >> >> I do not understand why this is necessary. The capability bits are an >> ABI >> that shouldn't change in a non-backward compat way (i.e. only additions). >> >> We typically don't export strings <-> number conversions for constants. >> I know you've explained this a few times before, but it still seems to me >> like a userspace only problem. What can userspace do with a capability >> it does not know about? > > When we run a userspace utility on the latest kernel, it has to be compiled > with kernel-headers which have same capability set at least. > If installed userspace utility does not support newly added capabilities, > it requires users to rebuild their utilities when they update the kernel. > > Typically, kernel developer faces this kind of version mismatching. > When they boots their kernel with new capabilities, it also requires to > rebuild libcap. Then, they have to revert it, when they boots with normal > kernel. > > If libcap can know what capabilities are supported on the running kernel > automatically, it does not need users to rebuild libcap concurrently. > > Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-05-14 0:36 ` KaiGai Kohei @ 2008-05-14 0:52 ` Chris Wright 2008-05-14 5:57 ` KaiGai Kohei 0 siblings, 1 reply; 32+ messages in thread From: Chris Wright @ 2008-05-14 0:52 UTC (permalink / raw) To: KaiGai Kohei Cc: Chris Wright, greg, morgan, serue, linux-security-module, linux-kernel * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote: > Chris, what is the status of the patch? I still don't understand how ... >> When we run a userspace utility on the latest kernel, it has to be compiled >> with kernel-headers which have same capability set at least. >> If installed userspace utility does not support newly added capabilities, >> it requires users to rebuild their utilities when they update the kernel. >> >> Typically, kernel developer faces this kind of version mismatching. >> When they boots their kernel with new capabilities, it also requires to >> rebuild libcap. Then, they have to revert it, when they boots with normal >> kernel. >> >> If libcap can know what capabilities are supported on the running kernel >> automatically, it does not need users to rebuild libcap concurrently. ...libcap can do anything meaningful here with capabilities it doesn't know about? This interface is already versioned, what is wrong is old cap version on new kernel (clearly new cap version on old kernel would have to fall back to older cap version)? thanks, -chris ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-05-14 0:52 ` Chris Wright @ 2008-05-14 5:57 ` KaiGai Kohei 2008-05-15 5:48 ` Andrew Morgan 0 siblings, 1 reply; 32+ messages in thread From: KaiGai Kohei @ 2008-05-14 5:57 UTC (permalink / raw) To: Chris Wright; +Cc: greg, morgan, serue, linux-security-module, linux-kernel Chris Wright wrote: > * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote: >> Chris, what is the status of the patch? > > I still don't understand how ... Hmm... >>> When we run a userspace utility on the latest kernel, it has to be compiled >>> with kernel-headers which have same capability set at least. >>> If installed userspace utility does not support newly added capabilities, >>> it requires users to rebuild their utilities when they update the kernel. >>> >>> Typically, kernel developer faces this kind of version mismatching. >>> When they boots their kernel with new capabilities, it also requires to >>> rebuild libcap. Then, they have to revert it, when they boots with normal >>> kernel. >>> >>> If libcap can know what capabilities are supported on the running kernel >>> automatically, it does not need users to rebuild libcap concurrently. > > ...libcap can do anything meaningful here with capabilities it doesn't > know about? This interface is already versioned, what is wrong is old > cap version on new kernel (clearly new cap version on old kernel would > have to fall back to older cap version)? The versioning info is just a hint in this case. The major purpose of this patch is to save steps of maintainance. When we tries to run a application using a new capability provided by the latest kernel, we have to rebuild libcap to follow kernel updates. If we can obtain an information what capabilities are supported in the running kernel, we don't need to rebuild libcap for the latest kernel everytime. For example, we got CAP_MAC_ADMIN at 2.6.25. If an application tries to use it, we have to replace libcap for 2.6.24 by libcap for 2.6.25. Although, we don't get any updates in libcap. :-( In addition, I noticed it will be usefull for applications which have a possibility to use arbitary number of capabilities, like busybox if setcap/getcap stuff is ported. (IMO, we should not use libcap for busybox, because its first priority is to reduce binary size, limited to minimun functionalities.) Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-05-14 5:57 ` KaiGai Kohei @ 2008-05-15 5:48 ` Andrew Morgan 2008-05-15 7:47 ` KaiGai Kohei 0 siblings, 1 reply; 32+ messages in thread From: Andrew Morgan @ 2008-05-15 5:48 UTC (permalink / raw) To: KaiGai Kohei Cc: Chris Wright, greg, serue, linux-security-module, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 KaiGai Kohei wrote: | For example, we got CAP_MAC_ADMIN at 2.6.25. If an application tries to | use it, we have to replace libcap for 2.6.24 by libcap for 2.6.25. | Although, we don't get any updates in libcap. :-( I'm not sure what you mean here. I think you will find that this particular capability was supported in libcap 2.03. Current is 2.09. Also, having Ack'd your proposed kernel patch, I speculatively included support for it in libcap-2.08. I will, of course, remove this support if the kernel doesn't adopt your change - or picks a different strategy... As it is, the patched kernel works nicely. :-) http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/ Cheers Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFIK86y+bHCR3gb8jsRAnV4AJ9gCaTwfKs8r7KX4DFixT84A5buOQCYlbaX mnMx52Yt2pRcLAXTOXElLA== =31Cy -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) 2008-05-15 5:48 ` Andrew Morgan @ 2008-05-15 7:47 ` KaiGai Kohei 0 siblings, 0 replies; 32+ messages in thread From: KaiGai Kohei @ 2008-05-15 7:47 UTC (permalink / raw) To: Andrew Morgan Cc: Chris Wright, greg, serue, linux-security-module, linux-kernel Andrew Morgan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > KaiGai Kohei wrote: > | For example, we got CAP_MAC_ADMIN at 2.6.25. If an application tries to > | use it, we have to replace libcap for 2.6.24 by libcap for 2.6.25. > | Although, we don't get any updates in libcap. :-( > > I'm not sure what you mean here. I think you will find that this > particular capability was supported in libcap 2.03. Current is 2.09. What I wanted to say is that we have to update/rebuild/reinstall userland packages using arbitary number of capabilities (like libcap) whenever the newer kernel adds a new capability, however, is it really necessary? Thanks, > Also, having Ack'd your proposed kernel patch, I speculatively included > support for it in libcap-2.08. I will, of course, remove this support if > the kernel doesn't adopt your change - or picks a different strategy... > As it is, the patched kernel works nicely. :-) > > http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/ > > Cheers > > Andrew > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD4DBQFIK86y+bHCR3gb8jsRAnV4AJ9gCaTwfKs8r7KX4DFixT84A5buOQCYlbaX > mnMx52Yt2pRcLAXTOXElLA== > =31Cy > -----END PGP SIGNATURE----- -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2008-05-15 7:48 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-02-25 6:06 [PATCH 0/3] exporting capability name/code pairs (final#2) Kohei KaiGai 2008-02-25 6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai 2008-02-25 6:51 ` Greg KH 2008-02-25 6:57 ` Kohei KaiGai 2008-02-25 7:47 ` Greg KH 2008-02-25 10:04 ` Kohei KaiGai 2008-02-26 20:09 ` Greg KH 2008-02-28 5:49 ` Valdis.Kletnieks 2008-03-03 4:42 ` Kohei KaiGai 2008-02-25 6:10 ` [PATCH 2/3] exporting capability name/code pairs (final#2) Kohei KaiGai 2008-02-26 14:55 ` Andrew G. Morgan 2008-02-26 20:58 ` Serge E. Hallyn 2008-03-07 4:30 ` Kohei KaiGai 2008-03-07 4:53 ` Greg KH 2008-02-25 6:10 ` [PATCH 3/3] a new example to use kobject/kobj_attribute (final#2) Kohei KaiGai 2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei 2008-04-22 11:17 ` [PATCH 1/3] add a private data field within kobj_attribute structure KaiGai Kohei 2008-04-22 11:18 ` [PATCH 2/3] exporting capability name/code pairs KaiGai Kohei 2008-04-22 11:18 ` [PATCH 3/3] a new example to use kobject/kobj_attribute KaiGai Kohei 2008-04-22 19:29 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) Alexey Dobriyan 2008-04-23 0:38 ` KaiGai Kohei 2008-04-23 7:03 ` Alexey Dobriyan 2008-04-23 7:37 ` KaiGai Kohei 2008-05-13 22:12 ` Alexey Dobriyan 2008-05-14 0:34 ` KaiGai Kohei 2008-04-23 5:37 ` Chris Wright 2008-04-23 7:15 ` KaiGai Kohei 2008-05-14 0:36 ` KaiGai Kohei 2008-05-14 0:52 ` Chris Wright 2008-05-14 5:57 ` KaiGai Kohei 2008-05-15 5:48 ` Andrew Morgan 2008-05-15 7:47 ` KaiGai Kohei
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).