exporting capability name/code pairs (final#2)

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

--

 Documentation/kobject.txt |    6 ++++++

Quoted 9 lines · 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.

Quoted 3 lines

Signed-off-by KaiGai Kohei <[email protected]>

--

 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.

Quoted 13 lines · Greg KH

Quoted 12 lines · 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.

Quoted 5 lines

Quoted 3 lines

Signed-off-by KaiGai Kohei <[email protected]>

--

 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?

Quoted 14 lines · Kohei KaiGai

Quoted 13 lines · Greg KH

Quoted 12 lines · 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 <[email protected]>

--

 Documentation/kobject.txt |    6 ++++++

Quoted 4 lines

Quoted 2 lines

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.

Quoted 23 lines · Greg KH

Quoted 22 lines · Kohei KaiGai

Quoted 14 lines · Greg KH

Quoted 13 lines · 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.

Quoted 5 lines

Quoted 3 lines

Signed-off-by KaiGai Kohei <[email protected]>

--

 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?

Quoted 2 lines

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?

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

Documentation/kobject.txt +0 -0

index bf3256e..efa5d71 100644
@@ -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

Quoted 8 lines · Kohei KaiGai

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

Documentation/kobject.txt +0 -0

index bf3256e..efa5d71 100644
@@ -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

Documentation/kobject.txt Both types of attributes used here, with a kobject that has been created · line 217

Quoted 10 lines

Documentation/kobject.txt +6 -0

 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?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Acked-by Andrew G. Morgan <[email protected]>

Tested-by Andrew G. Morgan <[email protected]>

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 <[email protected]>
| --
|  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 <[email protected]>
| +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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 5 lines · Andrew G. Morgan

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Acked-by Andrew G. Morgan <[email protected]>

Tested-by Andrew G. Morgan <[email protected]>

Also

Acked-by Serge Hallyn <[email protected]>

Tested-by Serge Hallyn <[email protected]>

thanks,
-serge

(plus you taught me a thing or two about kernel makefiles...)

Quoted 253 lines

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 <[email protected]>
| --
|  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 <[email protected]>
| +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)

Quoted 8 lines

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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

$ 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

Quoted 9 lines · KaiGai Kohei

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

Quoted 13 lines

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

security/commoncap.c +33 -0

@@ -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),

security/commoncap.c +37 -0

+};
+
+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

Quoted 25 lines · Alexey Dobriyan

Quoted 9 lines · KaiGai Kohei

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

Quoted 15 lines

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

Quoted 12 lines

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.

Quoted 36 lines · KaiGai Kohei

Quoted 35 lines · Alexey Dobriyan

Quoted 9 lines · KaiGai Kohei

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

Quoted 13 lines

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()!

Quoted 2 lines

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?

Quoted 1 line

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

Quoted 27 lines

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

Quoted 8 lines

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

Quoted 42 lines

Quoted 1 line

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

Quoted 27 lines

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

Quoted 8 lines

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?

Quoted 7 lines

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.

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

Quoted 10 lines · * KaiGai Kohei ([email protected]) 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.

Quoted 5 lines

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?

Quoted 17 lines · Chris Wright

Quoted 10 lines · * KaiGai Kohei ([email protected]) 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.

Quoted 5 lines

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.

Quoted 7 lines

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,

Chris, what is the status of the patch?

Quoted 5 lines

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.

Quoted 7 lines

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.

Quoted 1 line · * KaiGai Kohei ([email protected]) wrote:

Chris, what is the status of the patch?

I still don't understand how ...

Quoted 10 lines

Quoted 10 lines

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.

Quoted 2 lines

Quoted 2 lines

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

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