[PATCH 0/3] exporting capability name/code pairs (final#2)

[PATCH 0/3] exporting capability name/code pairs (final#2)

[Kohei KaiGai]

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>

[PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Kohei KaiGai]

[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>

[PATCH 2/3] exporting capability name/code pairs (final#2)

[Kohei KaiGai]

[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>

[PATCH 3/3] a new example to use kobject/kobj_attribute (final#2)

[Kohei KaiGai]

[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>

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Greg KH]

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

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Kohei KaiGai]

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>

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Greg KH]

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

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Kohei KaiGai]

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>

Re: [PATCH 2/3] exporting capability name/code pairs (final#2)

[Andrew G. Morgan]

-----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-----

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Greg KH]

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

Re: [PATCH 2/3] exporting capability name/code pairs (final#2)

[Serge E. Hallyn]

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

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Valdis.Kletnieks]

[-- 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 --]

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Kohei KaiGai]

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>

Re: [PATCH 2/3] exporting capability name/code pairs (final#2)

[Kohei KaiGai]

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>

Re: [PATCH 2/3] exporting capability name/code pairs (final#2)

[Greg KH]

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

[PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>

[PATCH 1/3] add a private data field within kobj_attribute structure.

[KaiGai Kohei]

[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>

[PATCH 2/3] exporting capability name/code pairs

[KaiGai Kohei]

[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>

[PATCH 3/3] a new example to use kobject/kobj_attribute

[KaiGai Kohei]

[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>

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[Alexey Dobriyan]

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

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[Chris Wright]

* 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

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[Alexey Dobriyan]

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?

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[Alexey Dobriyan]

>> 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.

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[Chris Wright]

* 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

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[Andrew Morgan]

-----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-----

Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

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>