subject:"\[PATCH\] Exporting capability code\/name pairs"

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

2008-02-19 Thread Kohei KaiGai

>> Could you also modify the documentation and the sample code to use this
>> new field, showing how it is to be used, and testing that it works
>> properly at the same time?
> 
> OK, Please wait for a while.

[3/3] Add a new example of kobject/attribute

The attached 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 refered by users.
It will make easier to share a single _show()/_store() method with several
entries.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 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..f99d734 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, "%d\n", (int) attr->data);
+}
+
+static ssize_t integer_store(struct kobject *kobj,
+struct kobj_attribute *attr,
+const char *buf, size_t count)
+{
+   int code;
+
+   sscanf(buf, "%du", &code);
+   attr->data = (void *) code;
+   return count;
+}
+
+static struct kobj_attribute hoge_attribute =
+   __ATTR_DATA(hoge, 0666, integer_show, integer_store, 123);
+static struct kobj_attribute piyo_attribute =
+   __ATTR_DATA(piyo, 0666, integer_show, integer_store, 456);
+static struct kobj_attribute fuga_attribute =
+   __ATTR_DATA(fuga, 0444, integer_show, NULL, 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 <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-19 Thread Kohei KaiGai

[Sorry, I sent a patch with TABs translated into spaces.]

In the attached patch, every attribute entry stores its capability
identifier in numerical or symbolic representation within private
data field of kobj_attribute structure.
The rest of them are unchanged.


[2/3] Exporting capability code/name pairs

This patch enables to export code/name of capabilities supported
on the running kernel.

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 this kernel. Thus, we have to maintain libcap version
in appropriate one synchronously.

This patch enables libcap to collect the list of capabilities on
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.

Please consider to put this patch on the queue of 2.6.25.

Thanks,
===
[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
cap_chowncap_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_bootcap_sys_tty_config
cap_ipc_lock cap_net_bind_service  cap_sys_chroot
cap_ipc_ownercap_net_broadcast cap_sys_module
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
0x20071026
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
cap_audit_control
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
20
[EMAIL PROTECTED] ~]$
===

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..402ef06 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 supported.
+
+   - /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/
+ returns its symbolic representation, on reading.
+ e.g) $ cat /sys/kernel/capability/codes/30
+  cap_audit_control
+
+   - /sys/kernel/capability/name/
+ 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

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

2008-02-19 Thread Kohei KaiGai

[Sorry, I sent a patch with TABs translated into spaces.]

[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. Anyone wants to use sysfs can store their private data to refer at
_show() and _store() method.
It enables to share a single method function with several similar entries,
like ones to export the list of capabilities the running kernel supported.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
-- 
 include/linux/kobject.h |1 +
 include/linux/sysfs.h   |7 +++
 2 files changed, 8 insertions(+), 0 deletions(-)

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 <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-19 Thread Greg KH

On Wed, Feb 20, 2008 at 02:38:16PM +0900, Kohei KaiGai wrote:
> Greg KH wrote:
>> On Wed, Feb 20, 2008 at 01:38:59PM +0900, Kohei KaiGai wrote:
> If we can have a private member in kobj_attribute, we can found the 
>>> content
> to be returned in a single step.
 Ok, again, just send me a patch that adds this functionality and we will
 be very glad to consider it.
>>> [1/2] Add a private data field within kobj_attribute structure.
>>>
>>> This patch add a private data field, declared as void *, within 
>>> kobj_attribute
>>> structure. Anyone wants to use sysfs can store their private data to 
>>> refer at
>>> _show() and _store() method.
>>> It enables to share a single method function with several similar 
>>> entries,
>>> like ones to export the list of capabilities the running kernel 
>>> supported.
>> But your patch 2/2 doesn't use this interface, why not?
>
> Really?
> The following two _show() methods shared by every capabilities refer
> the private member of kobj_attribute.
>
> | +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, "%d\n", (int) 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);
> | +}

Ah, sorry, missed that.  I also missed where this was set up as well :(

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-19 Thread Kohei KaiGai


Greg KH wrote:

On Wed, Feb 20, 2008 at 01:38:59PM +0900, Kohei KaiGai wrote:
If we can have a private member in kobj_attribute, we can found the 

content

to be returned in a single step.

Ok, again, just send me a patch that adds this functionality and we will
be very glad to consider it.

[1/2] Add a private data field within kobj_attribute structure.

This patch add a private data field, declared as void *, within 
kobj_attribute
structure. Anyone wants to use sysfs can store their private data to refer 
at

_show() and _store() method.
It enables to share a single method function with several similar entries,
like ones to export the list of capabilities the running kernel supported.


But your patch 2/2 doesn't use this interface, why not?


Really?
The following two _show() methods shared by every capabilities refer
the private member of kobj_attribute.

| +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, "%d\n", (int) 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);
| +}


 include/linux/kobject.h |1 +
 include/linux/sysfs.h   |7 +++
 2 files changed, 8 insertions(+), 0 deletions(-)

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


Hm, can you really use this?


Yes,


 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),  \
+}


I don't see how this would be any different from the original?  You are
always passed a kobject, which can be embedded in anything else.


The intension of the latest patch is same as the version which uses
capability_attribute structure.
It enables to store the content to be returned in the expanded field.
Applying kobj_attribute killed needs to declare my own structure.

However, every entries had its own _show() method, generated by macros
automatically, in the previous version. It fundamentally differ from
the latest one.


Could you also modify the documentation and the sample code to use this
new field, showing how it is to be used, and testing that it works
properly at the same time?


OK, Please wait for a while.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-19 Thread Greg KH

On Wed, Feb 20, 2008 at 01:38:59PM +0900, Kohei KaiGai wrote:
> >> If we can have a private member in kobj_attribute, we can found the 
> content
> >> to be returned in a single step.
> >
> > Ok, again, just send me a patch that adds this functionality and we will
> > be very glad to consider it.
>
> [1/2] Add a private data field within kobj_attribute structure.
>
> This patch add a private data field, declared as void *, within 
> kobj_attribute
> structure. Anyone wants to use sysfs can store their private data to refer 
> at
> _show() and _store() method.
> It enables to share a single method function with several similar entries,
> like ones to export the list of capabilities the running kernel supported.

But your patch 2/2 doesn't use this interface, why not?

>  include/linux/kobject.h |1 +
>  include/linux/sysfs.h   |7 +++
>  2 files changed, 8 insertions(+), 0 deletions(-)
>
> 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 */

Hm, can you really use this?

>  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),  \
> +}

I don't see how this would be any different from the original?  You are
always passed a kobject, which can be embedded in anything else.

Could you also modify the documentation and the sample code to use this
new field, showing how it is to be used, and testing that it works
properly at the same time?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] exporting capability code/name pairs (try #6)

2008-02-19 Thread Kohei KaiGai


Greg KH wrote:

On Mon, Feb 18, 2008 at 05:45:46PM +0900, Kohei KaiGai wrote:

Greg KH wrote:

Also, this code can be cleaned up a lot by just using the basic kobject
attributes, and not rolling your own types here.

I replaced my own defined capability_attribute by kobj_attribute.

It made the patch cleaned up, however, it also impossible to share a single
_show() method instance, because kobj_attribute does not have any private 
member.
Is there any reason why kobj_attribute does not have "void *private;"?

Because no one has asked for it?  :)

Or you can just do as the example in samples/kobject/ does it, no need
for the void pointer as that code shows.

It shows us a good example in samples/kobject.

However, it is unsuitable to export the list of capabilities.
The shared _show() method (b_show) calls strcmp() once with the name of kobject
attribute to switch its returning string.
If we have 34 of candidates to be returned, like the capability case, we have
to call strcmp() 33 times in maximum.

If we can have a private member in kobj_attribute, we can found the content
to be returned in a single step.


Ok, again, just send me a patch that adds this functionality and we will
be very glad to consider it.


In the attached patch, every attribute entry stores its capability
identifier in numerical or symbolic representation within private
data field of kobj_attribute structure.
The rest of them are unchanged.


[2/2] Exporting capability code/name pairs

This patch enables to export code/name of capabilities supported
on the running kernel.

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 this kernel. Thus, we have to maintain libcap version
in appropriate one synchronously.

This patch enables libcap to collect the list of capabilities on
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.

Please consider to put this patch on the queue of 2.6.25.

Thanks,
===
[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
cap_chowncap_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_bootcap_sys_tty_config
cap_ipc_lock cap_net_bind_service  cap_sys_chroot
cap_ipc_ownercap_net_broadcast cap_sys_module
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
0x20071026
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
cap_audit_control
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
20
[EMAIL PROTECTED] ~]$
===

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..402ef06 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 supported.
+
+   - /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/
+ returns its symbolic representation, on reading.
+ e.g) $ cat /sys/kernel/capability/codes/30
+  cap_audit_control
+
+   - /sys/kernel/capability/name/
+ returns its numerical representation, on reading.
+ e.g) $ cat /sys/kernel/ca

[PATCH] exporting capability code/name pairs (try #6)

2008-02-19 Thread Kohei KaiGai


>> If we can have a private member in kobj_attribute, we can found the content
>> to be returned in a single step.
>
> Ok, again, just send me a patch that adds this functionality and we will
> be very glad to consider it.

[1/2] Add a private data field within kobj_attribute structure.

This patch add a private data field, declared as void *, within kobj_attribute
structure. Anyone wants to use sysfs can store their private data to refer at
_show() and _store() method.
It enables to share a single method function with several similar entries,
like ones to export the list of capabilities the running kernel supported.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 include/linux/kobject.h |1 +
 include/linux/sysfs.h   |7 +++
 2 files changed, 8 insertions(+), 0 deletions(-)

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 <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-19 Thread Greg KH

On Mon, Feb 18, 2008 at 05:45:46PM +0900, Kohei KaiGai wrote:
> Greg KH wrote:
> >>> Also, this code can be cleaned up a lot by just using the basic kobject
> >>> attributes, and not rolling your own types here.
> >> I replaced my own defined capability_attribute by kobj_attribute.
> >>
> >> It made the patch cleaned up, however, it also impossible to share a single
> >> _show() method instance, because kobj_attribute does not have any private 
> >> member.
> >> Is there any reason why kobj_attribute does not have "void *private;"?
> > 
> > Because no one has asked for it?  :)
> > 
> > Or you can just do as the example in samples/kobject/ does it, no need
> > for the void pointer as that code shows.
> 
> It shows us a good example in samples/kobject.
> 
> However, it is unsuitable to export the list of capabilities.
> The shared _show() method (b_show) calls strcmp() once with the name of 
> kobject
> attribute to switch its returning string.
> If we have 34 of candidates to be returned, like the capability case, we have
> to call strcmp() 33 times in maximum.
> 
> If we can have a private member in kobj_attribute, we can found the content
> to be returned in a single step.

Ok, again, just send me a patch that adds this functionality and we will
be very glad to consider it.

thnaks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-18 Thread Serge E. Hallyn

Quoting Greg KH ([EMAIL PROTECTED]):
> On Mon, Feb 18, 2008 at 04:12:53PM +0900, Kohei KaiGai wrote:
> > Greg KH wrote:
> > > On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote:
> > >>> 
> > >>> This patch enables to export code/name of capabilities supported
> > >>> on the running kernel.
> > >>>
> > >>> 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 this kernel. Thus, we have to maintain libcap version
> > >>> in appropriate one synchronously.
> > >>>
> > >>> This patch enables libcap to collect the list of capabilities on
> > >>> 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.
> > >>>
> > >>> Please consider to put this patch on the queue of 2.6.25.
> > >> Looks good, except don't you need to put the code in commoncap.c under a
> > >> #ifdef SYSFS?
> > 
> > Fair enough.
> > I added the #ifdef - #endif block in this patch.
> 
> Not needed, if SYSFS is not build in, all of that code pretty much
> compiles away to nothing.  So you can drop that.

Oops.  Sorry.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-18 Thread Kohei KaiGai

Greg KH wrote:
> On Mon, Feb 18, 2008 at 04:12:53PM +0900, Kohei KaiGai wrote:
>> Greg KH wrote:
>>> On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote:
> 
> This patch enables to export code/name of capabilities supported
> on the running kernel.
>
> 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 this kernel. Thus, we have to maintain libcap version
> in appropriate one synchronously.
>
> This patch enables libcap to collect the list of capabilities on
> 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.
>
> Please consider to put this patch on the queue of 2.6.25.
 Looks good, except don't you need to put the code in commoncap.c under a
 #ifdef SYSFS?
>> Fair enough.
>> I added the #ifdef - #endif block in this patch.
> 
> Not needed, if SYSFS is not build in, all of that code pretty much
> compiles away to nothing.  So you can drop that.

Hmm..., I reverted these #ifdef and #endif in this version.

>>> Also, this code can be cleaned up a lot by just using the basic kobject
>>> attributes, and not rolling your own types here.
>> I replaced my own defined capability_attribute by kobj_attribute.
>>
>> It made the patch cleaned up, however, it also impossible to share a single
>> _show() method instance, because kobj_attribute does not have any private 
>> member.
>> Is there any reason why kobj_attribute does not have "void *private;"?
> 
> Because no one has asked for it?  :)
> 
> Or you can just do as the example in samples/kobject/ does it, no need
> for the void pointer as that code shows.

It shows us a good example in samples/kobject.

However, it is unsuitable to export the list of capabilities.
The shared _show() method (b_show) calls strcmp() once with the name of kobject
attribute to switch its returning string.
If we have 34 of candidates to be returned, like the capability case, we have
to call strcmp() 33 times in maximum.

If we can have a private member in kobj_attribute, we can found the content
to be returned in a single step.

>> +static struct kobj_attribute cap_version_attr = {
>> +.attr = { .name = "version", .mode = 0444 },
>> +.show = capability_version_show,
>> +};
> 
> We do have macros for these kinds of things :)
> 
> Look at ATTR() and friends.

OK, fixed.
I applied __ATTR() instead.

>> +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);
>> +#endif  /* CONFIG_SYSFS */
> 
> Where do you remove these files?  Or will that never happen?

Removing these files are never happen.

Thanks,

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 Documentation/ABI/testing/sysfs-kernel-capability |   23 +
 scripts/mkcapnames.sh |   44 ++
 security/Makefile |9 ++
 security/commoncap.c  |   94 +
 4 files changed, 170 insertions(+), 0 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-kernel-capability 
b/Documentation/ABI/testing/sysfs-kernel-capability
index e69de29..402ef06 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 run

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

2008-02-17 Thread Greg KH

On Mon, Feb 18, 2008 at 04:12:53PM +0900, Kohei KaiGai wrote:
> Greg KH wrote:
> > On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote:
> >>> 
> >>> This patch enables to export code/name of capabilities supported
> >>> on the running kernel.
> >>>
> >>> 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 this kernel. Thus, we have to maintain libcap version
> >>> in appropriate one synchronously.
> >>>
> >>> This patch enables libcap to collect the list of capabilities on
> >>> 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.
> >>>
> >>> Please consider to put this patch on the queue of 2.6.25.
> >> Looks good, except don't you need to put the code in commoncap.c under a
> >> #ifdef SYSFS?
> 
> Fair enough.
> I added the #ifdef - #endif block in this patch.

Not needed, if SYSFS is not build in, all of that code pretty much
compiles away to nothing.  So you can drop that.

> 
> >>> ===
> >>> [EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
> >>> cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
> >>> cap_chowncap_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_ownercap_net_broadcast cap_sys_module
> >>> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
> >>> 0x20071026
> >>> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
> >>> cap_audit_control
> >>> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
> >>> 20
> >>> [EMAIL PROTECTED] ~]$
> >>> ===
> > 
> > As you are adding new sysfs entries, please also add the needed
> > Documentation/ABI/ entries as well.
> 
> OK, I'll add a short description at Documentation/ABI/sysfs-kernel-capability 
> .

Thank you.

> > Also, this code can be cleaned up a lot by just using the basic kobject
> > attributes, and not rolling your own types here.
> 
> I replaced my own defined capability_attribute by kobj_attribute.
> 
> It made the patch cleaned up, however, it also impossible to share a single
> _show() method instance, because kobj_attribute does not have any private 
> member.
> Is there any reason why kobj_attribute does not have "void *private;"?

Because no one has asked for it?  :)

Or you can just do as the example in samples/kobject/ does it, no need
for the void pointer as that code shows.



> 
> Thanks,
> Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
> --
>  Documentation/ABI/testing/sysfs-kernel-capability |   23 +
>  scripts/mkcapnames.sh |   44 +
>  security/Makefile |9 ++
>  security/commoncap.c  |  102 
> +
>  4 files changed, 178 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-kernel-capability 
> b/Documentation/ABI/testing/sysfs-kernel-capability
> index e69de29..402ef06 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 supported.
> +
> + - /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/
> +   returns its symbolic representation, on reading.
> +   e.g) $ cat /sys/kernel/capability/codes/30
> +cap_audit_control
> +
> + - /sys/kernel/capability/name/
> +

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

2008-02-17 Thread Kohei KaiGai

Greg KH wrote:
> On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote:
>>> 
>>> This patch enables to export code/name of capabilities supported
>>> on the running kernel.
>>>
>>> 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 this kernel. Thus, we have to maintain libcap version
>>> in appropriate one synchronously.
>>>
>>> This patch enables libcap to collect the list of capabilities on
>>> 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.
>>>
>>> Please consider to put this patch on the queue of 2.6.25.
>> Looks good, except don't you need to put the code in commoncap.c under a
>> #ifdef SYSFS?

Fair enough.
I added the #ifdef - #endif block in this patch.

>>> ===
>>> [EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
>>> cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
>>> cap_chowncap_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_ownercap_net_broadcast cap_sys_module
>>> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
>>> 0x20071026
>>> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
>>> cap_audit_control
>>> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
>>> 20
>>> [EMAIL PROTECTED] ~]$
>>> ===
> 
> As you are adding new sysfs entries, please also add the needed
> Documentation/ABI/ entries as well.

OK, I'll add a short description at Documentation/ABI/sysfs-kernel-capability .

> Also, this code can be cleaned up a lot by just using the basic kobject
> attributes, and not rolling your own types here.

I replaced my own defined capability_attribute by kobj_attribute.

It made the patch cleaned up, however, it also impossible to share a single
_show() method instance, because kobj_attribute does not have any private 
member.
Is there any reason why kobj_attribute does not have "void *private;"?

Thanks,
Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 Documentation/ABI/testing/sysfs-kernel-capability |   23 +
 scripts/mkcapnames.sh |   44 +
 security/Makefile |9 ++
 security/commoncap.c  |  102 +
 4 files changed, 178 insertions(+), 0 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-kernel-capability 
b/Documentation/ABI/testing/sysfs-kernel-capability
index e69de29..402ef06 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 supported.
+
+   - /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/
+ returns its symbolic representation, on reading.
+ e.g) $ cat /sys/kernel/capability/codes/30
+  cap_audit_control
+
+   - /sys/kernel/capability/name/
+ 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

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

2008-02-15 Thread Greg KH

On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote:
> Quoting Kohei KaiGai ([EMAIL PROTECTED]):
> > Li Zefan wrote:
> >  - snip -
> > >> +error1:
> > >> +kobject_put(capability_kobj);
> > >> +error0:
> > >> +printk(KERN_ERR "Unable to export capabilities\n");
> > >> +
> > >> +return 0;
> > > 
> > > Should return -EFXXX ..
> > 
> > Oops,
> > I fixed it as follows. Thanks for your pointed out.
> > 
> > 
> > This patch enables to export code/name of capabilities supported
> > on the running kernel.
> > 
> > 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 this kernel. Thus, we have to maintain libcap version
> > in appropriate one synchronously.
> > 
> > This patch enables libcap to collect the list of capabilities on
> > 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.
> > 
> > Please consider to put this patch on the queue of 2.6.25.
> 
> Looks good, except don't you need to put the code in commoncap.c under a
> #ifdef SYSFS?
> 
> thanks,
> -serge
> 
> > 
> > Thanks,
> > ===
> > [EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
> > cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
> > cap_chowncap_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_ownercap_net_broadcast cap_sys_module
> > [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
> > 0x20071026
> > [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
> > cap_audit_control
> > [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
> > 20
> > [EMAIL PROTECTED] ~]$
> > ===

As you are adding new sysfs entries, please also add the needed
Documentation/ABI/ entries as well.

Also, this code can be cleaned up a lot by just using the basic kobject
attributes, and not rolling your own types here.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-15 Thread Serge E. Hallyn

Quoting Kohei KaiGai ([EMAIL PROTECTED]):
> Li Zefan wrote:
>  - snip -
> >> +error1:
> >> +  kobject_put(capability_kobj);
> >> +error0:
> >> +  printk(KERN_ERR "Unable to export capabilities\n");
> >> +
> >> +  return 0;
> > 
> > Should return -EFXXX ..
> 
> Oops,
> I fixed it as follows. Thanks for your pointed out.
> 
> 
> This patch enables to export code/name of capabilities supported
> on the running kernel.
> 
> 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 this kernel. Thus, we have to maintain libcap version
> in appropriate one synchronously.
> 
> This patch enables libcap to collect the list of capabilities on
> 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.
> 
> Please consider to put this patch on the queue of 2.6.25.

Looks good, except don't you need to put the code in commoncap.c under a
#ifdef SYSFS?

thanks,
-serge

> 
> Thanks,
> ===
> [EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
> cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
> cap_chowncap_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_bootcap_sys_tty_config
> cap_ipc_lock cap_net_bind_service  cap_sys_chroot
> cap_ipc_ownercap_net_broadcast cap_sys_module
> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
> 0x20071026
> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
> cap_audit_control
> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
> 20
> [EMAIL PROTECTED] ~]$
> ===
> 
> Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
> --
>  scripts/mkcapnames.sh |   44 ++
>  security/Makefile |9 
>  security/commoncap.c  |  118 
> +
>  3 files changed, 171 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..c1ffc00 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

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

2008-02-14 Thread Kohei KaiGai

Li Zefan wrote:
 - snip -
>> +error1:
>> +kobject_put(capability_kobj);
>> +error0:
>> +printk(KERN_ERR "Unable to export capabilities\n");
>> +
>> +return 0;
> 
> Should return -EFXXX ..

Oops,
I fixed it as follows. Thanks for your pointed out.


This patch enables to export code/name of capabilities supported
on the running kernel.

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 this kernel. Thus, we have to maintain libcap version
in appropriate one synchronously.

This patch enables libcap to collect the list of capabilities on
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.

Please consider to put this patch on the queue of 2.6.25.

Thanks,
===
[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
cap_chowncap_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_bootcap_sys_tty_config
cap_ipc_lock cap_net_bind_service  cap_sys_chroot
cap_ipc_ownercap_net_broadcast cap_sys_module
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
0x20071026
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
cap_audit_control
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
20
[EMAIL PROTECTED] ~]$
===

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 scripts/mkcapnames.sh |   44 ++
 security/Makefile |9 
 security/commoncap.c  |  118 +
 3 files changed, 171 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..c1ffc00 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 $(src)/../scripts/mkcapnames.sh > $@
+targets += cap_names.h
+$(obj)/cap_names.h: $(src)/../scripts/mkcapnames.sh 
$(src)/../include/linux/capability.h FORCE
+   $(call if_changed,cap_names)
diff --git a/security/commoncap.c b/security/commoncap.c
index

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

2008-02-14 Thread Li Zefan

Kohei KaiGai wrote:

<...snip...>

> +static int __init capability_export_names(void)
> +{
> + /* make /sys/kernel/capability */
> + capability_kobj = kobject_create_and_add("capability", kernel_kobj);
> + if (!capability_kobj)
> + goto error0;
> +
> + /* make /sys/kernel/capability/names */
> + if (sysfs_create_group(capability_kobj,
> +&capability_name_attr_group))
> + goto error1;
> +
> + /* make /sys/kernel/capability/codes */
> + if (sysfs_create_group(capability_kobj,
> +&capability_code_attr_group))
> + goto error2;
> +
> + if (sysfs_create_file(capability_kobj,
> +   &cap_version_attr.attr))
> + 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 0;

Should return -EFXXX ..

> +}
> +__initcall(capability_export_names);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] exporting capability code/name pairs (try #5)

2008-02-14 Thread Kohei KaiGai

This patch enables to export code/name of capabilities supported
on the running kernel.

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 this kernel. Thus, we have to maintain libcap version
in appropriate one synchronously.

This patch enables libcap to collect the list of capabilities on
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.

Please consider to put this patch on the queue of 2.6.25.

Thanks,
===
[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
cap_chowncap_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_bootcap_sys_tty_config
cap_ipc_lock cap_net_bind_service  cap_sys_chroot
cap_ipc_ownercap_net_broadcast cap_sys_module
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
0x20071026
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
cap_audit_control
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
20
[EMAIL PROTECTED] ~]$
===

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 scripts/mkcapnames.sh |   44 +++
 security/Makefile |9 
 security/commoncap.c  |  112 +
 3 files changed, 165 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..c1ffc00 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 $(src)/../scripts/mkcapnames.sh > $@
+targets += cap_names.h
+$(obj)/cap_names.h: $(src)/../scripts/mkcapnames.sh 
$(src)/../include/linux/capability.h FORCE
+   $(call if_changed,cap_names)
diff --git a/security/commoncap.c b/security/commoncap.c
index 5aba826..896b080 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 /* Global security state */

@@ -637,3 +639,113 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages)

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

2008-02-13 Thread Kohei KaiGai


Alexey Dobriyan wrote:

On Tue, Feb 12, 2008 at 10:10:06AM +0900, Kohei KaiGai wrote:

Alexey Dobriyan wrote:

On Fri, Feb 08, 2008 at 06:42:09PM +0900, Kohei KaiGai wrote:

[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
cap_chowncap_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_ownercap_net_broadcast cap_sys_module
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/20
cap_sys_pacct
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_mknod
27
[EMAIL PROTECTED] ~]$

Any comment please.

You don't like 1 (one) /proc/capabilities, why?
I have no preference whether a single /proc/capabilities, or the current 
approach.
However, this idea requires a bit more cost to lookup a capability not 
sequencially.


And I'm sure far less memory wasted at runtime.

Also, adding config option for one file/directory seems ridiculous to
me. And changelog completely fails to mention why it is useful to lookup
capabilities by name and number -- CAP_SYS_* numbers are part of ABI,
they won't change.


The codes of capabilities are not removed/modified, but a new one
may be added. In actually, two capabilities will be added at 2.6.25.
If we don't have dynamic interface to obtain the list of capabilities,
libcap built on older kernel cannot work enough on the latest one.

I'll add a description to make clear its purpose in the next patch.
Please wait for a while.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-13 Thread Kohei KaiGai


Serge E. Hallyn wrote:

Quoting Kohei KaiGai ([EMAIL PROTECTED]):

diff --git a/security/Kconfig b/security/Kconfig
index 25ffe1b..b79e830 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -91,6 +91,15 @@ config SECURITY_FILE_CAPABILITIES

  If in doubt, answer N.

+config SECURITY_CAPABILITIES_EXPORT
+   bool "Exporting capabilities kernel supported"
+   depends on SECURITY_CAPABILITIES && SYSFS


Oh no, we're being bit by this again...  When SECURITY=n, capabilities
are compiled in but SECURITY_CAPABILITIES=n.

Months ago I floated the following patch so we'd have a CONFIG variable
to let us know whether commoncap is compiled in.  You might want to use
this and depend on CONFIG_COMMONCAP?  (Though really I personally don't
think you need your own config variable for this)


I also think its own config variable is not necessary to turn on/off
exporting the list of capabilities in actually.
Do you want this feture to be moved into security/commoncap.c and
enabled unconditionally? I can agree this suggestion.

Is there any complaint for this idea?

Thanks,


Other than that, this tested fine for me.

thanks,
-serge


From 54c70ca7671750fe8986451fae91d42107d0ca90 Mon Sep 17 00:00:00 2001

From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Fri, 28 Sep 2007 10:33:33 -0500
Subject: [PATCH 1/2] capabilities: define CONFIG_COMMONCAP

currently the compilation of commoncap.c is determined
through Makefile logic.  So there is no single CONFIG
variable which can be relied upon to know whether it
will be compiled.

Define CONFIG_COMMONCAP to be true when lsm is not
compiled in, or when the capability or rootplug modules
are compiled.  These are the cases when commoncap is
currently compiled.  Use this variable in security/Makefile
to determine commoncap.c's compilation.

Apart from being a logic cleanup, this is needed by the
upcoming cap_bset patch so that prctl can know whether
PR_SET_BSET should be allowed.

Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
 security/Kconfig  |4 
 security/Makefile |9 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 8086e61..02b33fa 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -103,6 +103,10 @@ config SECURITY_ROOTPLUG
 	  
 	  If you are unsure how to answer this question, answer N.
 
+config COMMONCAP

+   bool
+   default !SECURITY || SECURITY_CAPABILITIES || SECURITY_ROOTPLUG
+
 source security/selinux/Kconfig
 
 endmenu

diff --git a/security/Makefile b/security/Makefile
index ef87df2..781 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -5,14 +5,11 @@
 obj-$(CONFIG_KEYS) += keys/
 subdir-$(CONFIG_SECURITY_SELINUX)  += selinux
 
-# if we don't select a security model, use the default capabilities

-ifneq ($(CONFIG_SECURITY),y)
-obj-y  += commoncap.o
-endif
+obj-$(CONFIG_COMMONCAP)+= commoncap.o
 
 # Object file lists

 obj-$(CONFIG_SECURITY) += security.o dummy.o inode.o
 # Must precede capability.o in order to stack properly.
 obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o
-obj-$(CONFIG_SECURITY_CAPABILITIES)+= commoncap.o capability.o
-obj-$(CONFIG_SECURITY_ROOTPLUG)+= commoncap.o root_plug.o
+obj-$(CONFIG_SECURITY_CAPABILITIES)+= capability.o
+obj-$(CONFIG_SECURITY_ROOTPLUG)+= root_plug.o



--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-12 Thread Alexey Dobriyan

On Tue, Feb 12, 2008 at 10:10:06AM +0900, Kohei KaiGai wrote:
> Alexey Dobriyan wrote:
> >On Fri, Feb 08, 2008 at 06:42:09PM +0900, Kohei KaiGai wrote:
> >>[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
> >>cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
> >>cap_chowncap_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_ownercap_net_broadcast cap_sys_module
> >>[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/20
> >>cap_sys_pacct
> >>[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_mknod
> >>27
> >>[EMAIL PROTECTED] ~]$
> >>
> >>Any comment please.
> >
> >You don't like 1 (one) /proc/capabilities, why?
> 
> I have no preference whether a single /proc/capabilities, or the current 
> approach.
> However, this idea requires a bit more cost to lookup a capability not 
> sequencially.

And I'm sure far less memory wasted at runtime.

Also, adding config option for one file/directory seems ridiculous to
me. And changelog completely fails to mention why it is useful to lookup
capabilities by name and number -- CAP_SYS_* numbers are part of ABI,
they won't change.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-12 Thread Serge E. Hallyn

Quoting Kohei KaiGai ([EMAIL PROTECTED]):
> This patch enables to export code/name pair of capabilities supported
> on the running kernel, under the /sys/kernel/capability .
> We can apply it onto the latest Linus's git tree.
> 
> Changes from the previous version:
> - I added "names/" ans "codes/" directories, and we can use them
>   to lookup capability code or name non-sequentially.
>   In the previous version, we had to scan whole of entries to lookup
>   capability name by its code.
>   (required by Andrew Morgan)
> - I added an assertion when "mkcapname.sh" works incorrectly.
>   (required by Serge E.Hallyn)
> 
> In addition, Andrew suggested me to export these translation by symlinks
> to reduce the number of invocation of system call.
> However, current sysfs interface does not allows to create symlinks with
> invalid indication.
> Thus, this patch exports them as regular files.
> 
> 
> [EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
> cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
> cap_chowncap_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_bootcap_sys_tty_config
> cap_ipc_lock cap_net_bind_service  cap_sys_chroot
> cap_ipc_ownercap_net_broadcast cap_sys_module
> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/20
> cap_sys_pacct
> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_mknod
> 27
> [EMAIL PROTECTED] ~]$
> 
> Any comment please.
> 
> Thanks,
> 
> Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
> 
>  scripts/mkcapnames.sh |   44 +++
>  security/Kconfig  |9 
>  security/Makefile |   11 +
>  security/capability.c |  115 
> +
>  4 files changed, 179 insertions(+), 0 deletions(-)
> 
> diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh
> index e69de29..9e7290f 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/Kconfig b/security/Kconfig
> index 25ffe1b..b79e830 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -91,6 +91,15 @@ config SECURITY_FILE_CAPABILITIES
> 
> If in doubt, answer N.
> 
> +config SECURITY_CAPABILITIES_EXPORT
> + bool "Exporting capabilities kernel supported"
> + depends on SECURITY_CAPABILITIES && SYSFS

Oh no, we're being bit by this again...  When SECURITY=n, capabilities
are compiled in but SECURITY_CAPABILITIES=n.

Months ago I floated the following patch so we'd have a CONFIG variable
to let us know whether commoncap is compiled in.  You might want to use
this and depend on CONFIG_COMMONCAP?  (Though really I personally don't
think you need your own config variable for this)

Other than that, this tested fine for me.

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

2008-02-11 Thread Kohei KaiGai


Alexey Dobriyan wrote:

On Fri, Feb 08, 2008 at 06:42:09PM +0900, Kohei KaiGai wrote:

[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
cap_chowncap_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_bootcap_sys_tty_config
cap_ipc_lock cap_net_bind_service  cap_sys_chroot
cap_ipc_ownercap_net_broadcast cap_sys_module
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/20
cap_sys_pacct
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_mknod
27
[EMAIL PROTECTED] ~]$

Any comment please.


You don't like 1 (one) /proc/capabilities, why?


I have no preference whether a single /proc/capabilities, or the current 
approach.
However, this idea requires a bit more cost to lookup a capability not 
sequencially.

Thank,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-11 Thread Kohei KaiGai


Andrew G. Morgan wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

KaiGai,

Thanks for trying to accommodate me :-)

Kohei KaiGai wrote:
| In addition, Andrew suggested me to export these translation by symlinks
| to reduce the number of invocation of system call.

Yes, I wanted to make use of readlink() instead of open()/read()/close()
to access each unknown capability.

| However, current sysfs interface does not allows to create symlinks with
| invalid indication.

:-(

| Thus, this patch exports them as regular files.

What about using symlinks for the name files and text content for the
numeric ones? You could even drop the names/ and codes/ subdirectories too:

$ cat /sys/kernel/capability/20
cap_sys_pacct
$ ls -l /sys/kernel/capability/cap_mknod
lr--r--r--  1 root root 64 Feb  8 08:26 cap_mknod -> 27
$ cat /sys/kernel/capability/names/cap_mknod
cap_mknod


Sysfs does not support to create symbolic links to regular files now.

The sysfs_create_link() is a function to create a symbolic link on sysfs.
However, it requires two kobjects as its arguments. One is to specify its
parent directory, the other is to specify the target of indirection.
It means the indicated target have to be a directory.

At include/linux/sysfs.h:
int __must_check sysfs_create_link(struct kobject *kobj, struct kobject *target,
   const char *name);

Please tell me, if I have any misunderstandings.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-08 Thread Alexey Dobriyan

On Fri, Feb 08, 2008 at 06:42:09PM +0900, Kohei KaiGai wrote:
> [EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
> cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
> cap_chowncap_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_bootcap_sys_tty_config
> cap_ipc_lock cap_net_bind_service  cap_sys_chroot
> cap_ipc_ownercap_net_broadcast cap_sys_module
> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/20
> cap_sys_pacct
> [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_mknod
> 27
> [EMAIL PROTECTED] ~]$
> 
> Any comment please.

You don't like 1 (one) /proc/capabilities, why?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2008-02-08 Thread Andrew G. Morgan


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

KaiGai,

Thanks for trying to accommodate me :-)

Kohei KaiGai wrote:
| In addition, Andrew suggested me to export these translation by symlinks
| to reduce the number of invocation of system call.

Yes, I wanted to make use of readlink() instead of open()/read()/close()
to access each unknown capability.

| However, current sysfs interface does not allows to create symlinks with
| invalid indication.

:-(

| Thus, this patch exports them as regular files.

What about using symlinks for the name files and text content for the
numeric ones? You could even drop the names/ and codes/ subdirectories too:

$ cat /sys/kernel/capability/20
cap_sys_pacct
$ ls -l /sys/kernel/capability/cap_mknod
lr--r--r--  1 root root 64 Feb  8 08:26 cap_mknod -> 27
$ cat /sys/kernel/capability/names/cap_mknod
cap_mknod

Cheers

Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHrIfh+bHCR3gb8jsRAkueAKDYMu+so+YCJD9klNentiWlwZJXlQCgrzSa
tWr1XM1nKcvST1ScAfO27j4=
=w5N/
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] exporting capability code/name pairs (try #4)

2008-02-08 Thread Kohei KaiGai

This patch enables to export code/name pair of capabilities supported
on the running kernel, under the /sys/kernel/capability .
We can apply it onto the latest Linus's git tree.

Changes from the previous version:
- I added "names/" ans "codes/" directories, and we can use them
  to lookup capability code or name non-sequentially.
  In the previous version, we had to scan whole of entries to lookup
  capability name by its code.
  (required by Andrew Morgan)
- I added an assertion when "mkcapname.sh" works incorrectly.
  (required by Serge E.Hallyn)

In addition, Andrew suggested me to export these translation by symlinks
to reduce the number of invocation of system call.
However, current sysfs interface does not allows to create symlinks with
invalid indication.
Thus, this patch exports them as regular files.


[EMAIL PROTECTED] ~]$ 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_controlcap_kill  cap_net_raw cap_sys_nice
cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
cap_chowncap_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_bootcap_sys_tty_config
cap_ipc_lock cap_net_bind_service  cap_sys_chroot
cap_ipc_ownercap_net_broadcast cap_sys_module
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/20
cap_sys_pacct
[EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_mknod
27
[EMAIL PROTECTED] ~]$

Any comment please.

Thanks,

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>

 scripts/mkcapnames.sh |   44 +++
 security/Kconfig  |9 
 security/Makefile |   11 +
 security/capability.c |  115 +
 4 files changed, 179 insertions(+), 0 deletions(-)

diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh
index e69de29..9e7290f 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/Kconfig b/security/Kconfig
index 25ffe1b..b79e830 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -91,6 +91,15 @@ config SECURITY_FILE_CAPABILITIES

  If in doubt, answer N.

+config SECURITY_CAPABILITIES_EXPORT
+   bool "Exporting capabilities kernel supported"
+   depends on SECURITY_CAPABILITIES && SYSFS
+   help
+ This enables to export any capabilities which are supported
+ in the running kernel.
+   
+ If you are unsure how to answer this question, answer Y.
+
 config SECURITY_ROOTPLUG
bool "Root Plug Support"
depends on USB=y && SECURITY
diff --git a/security/Makefile b/security/Makefile
index 9e8b025..0e80903 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -18,3 +18,14 @@ 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 r

Re: [PATCH] Exporting capability code/name pairs

2008-01-03 Thread KaiGai Kohei

James Morris wrote:
> On Wed, 2 Jan 2008, KaiGai Kohei wrote:
> 
>>> Another issue is that securityfs depends on CONFIG_SECURITY, which might be
>>> undesirable, given that capabilities are a standard feature.
>> We can implement this feature on another pseudo filesystems.
>> Do you think what filesystem is the best candidate?
>> I prefer procfs or sysfs instead.
> 
> Sysfs makes more sense, as this information is system-wide and does not 
> relate to specific processes.

The following patch enables to export any capabilities which are supported
on the working kernel, under the /sys/kernel/capability.
You can obtain the code/name pairs of capabilities with scanning this directory.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 kernel/Makefile   |9 +
 kernel/capability.c   |   36 
 scripts/mkcapnames.sh |   45 +
 3 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/kernel/Makefile b/kernel/Makefile
index dfa9695..29cd3ac 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -80,3 +80,12 @@ quiet_cmd_ikconfiggz = IKCFG   $@
 targets += config_data.h
 $(obj)/config_data.h: $(obj)/config_data.gz FORCE
$(call if_changed,ikconfiggz)
+
+# cap_names.h contains the code/name pair of capabilities.
+# It is generated using include/linux/capability.h automatically.
+$(obj)/capability.o: $(obj)/cap_names.h
+quiet_cmd_cap_names  = CAPS$@
+  cmd_cap_names  = /bin/sh $(src)/../scripts/mkcapnames.sh > $@
+targets += cap_names.h
+$(obj)/cap_names.h: $(src)/../scripts/mkcapnames.sh 
$(src)/../include/linux/capability.h FORCE
+   $(call if_changed,cap_names)
diff --git a/kernel/capability.c b/kernel/capability.c
index efbd9cd..14b4f4b 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -245,3 +245,39 @@ int capable(int cap)
return __capable(current, cap);
 }
 EXPORT_SYMBOL(capable);
+
+/*
+ * Export the list of capabilities on /sys/kernel/capability
+ */
+#define SYSFS_CAPABILITY_ENTRY(_name, _fmt, ...)   \
+   static ssize_t _name##_show(struct kset *kset, char *buffer)\
+   {   \
+   return scnprintf(buffer, PAGE_SIZE, _fmt, __VA_ARGS__); \
+   }   \
+   static struct subsys_attribute _name##_attr = __ATTR_RO(_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_attr_group = {
+   .name = "capability",
+   .attrs = capability_attrs,
+};
+
+static int __init capability_export_names(void)
+{
+   int rc;
+
+   rc = sysfs_create_group(&kernel_subsys.kobj,
+   &capability_attr_group);
+   if (rc) {
+   printk(KERN_ERR "Unable to export capabilities\n");
+   return rc;
+   }
+
+   return 0;
+}
+__initcall(capability_export_names);
diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh
index e69de29..c1c8b1f 100644
--- a/scripts/mkcapnames.sh
+++ b/scripts/mkcapnames.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+#
+# generate a cap_names.h file from include/linux/capability.h
+#
+
+BASEDIR=`dirname $0`
+
+echo '#ifndef CAP_NAMES_H'
+echo '#define CAP_NAMES_H'
+echo
+echo '#ifndef SYSFS_CAPABILITY_ENTRY'
+echo '#error cap_names.h should be included from kernel/capability.c'
+echo '#else'
+
+echo 'SYSFS_CAPABILITY_ENTRY(version, "0x%08x\n", _LINUX_CAPABILITY_VERSION);'
+
+cat ${BASEDIR}/../include/linux/capability.h   \
+| egrep '^#define CAP_[A-Z_]+[ ]+[0-9]+$'  \
+| awk 'BEGIN {
+max_code = -1;
+}
+{
+if ($3 > max_code)
+max_code = $3;
+printf("\tSYSFS_CAPABILITY_ENTRY(%s, \"%%u\\n\", %s);\n", 
tolower($2), $2);
+}
+END {
+printf("\tSYSFS_CAPABILITY_ENTRY(index, \"%%u\\n\", %u);\n", 
max_code);
+}'
+
+echo
+echo 'static struct attribute *capability_attrs[] = {'
+echo '&version_attr.attr,'
+echo '&index_attr.attr,'
+
+cat ${BASEDIR}/../include/linux/capability.h\
+| egrep '^#define CAP_[A-Z_]+[ ]+[0-9]+$'   \
+| awk '{ printf ("&%s_attr.attr,\n", tolower($2)); }'
+
+echo 'NULL,'
+echo '};'
+
+echo '#endif   /* SYSFS_CAPABILITY_ENTRY */'
+echo '#endif   /* CAP_NAMES_H */'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2008-01-03 Thread KaiGai Kohei

> There is also the issue of compiled code which explicitly raises and
> lowers capabilities around critical code sections (ie., as they were
> intended to be used) is also not well served by this change.
> 
> That is, unless the code was compiled with things like CAP_MAC_ADMIN
> being #define'd then it won't be able to do things like cap_set_flag()
> appropriately.

A new function will be necessary, like:
cap_value_t cap_get_value_by_name(const char *cap_name);

If a program tries to use specific capabilities explicitly, it can
apply pre-defined capability code like CAP_MAC_ADMIN.

However, when we implement a program which can deal with arbitrary
capabilities, it should obtain codes of them dynamically, because
it enables to work itself on the feature kernel.

Thanks,

> Cheers
> 
> Andrew
> 
> KaiGai Kohei wrote:
>> Andrew Morgan wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> KaiGai Kohei wrote:
 Remaining issues:
 - We have to mount securityfs explicitly, or use /etc/fstab.
   It can cause a matter when we want to use this feature on
   very early phase on boot. (like /sbin/init)
>>> I'm not altogether clear how you intend this to work.
>>>
>>> Are you saying that some future version of libcap will require that
>>> securityfs be mounted before it (libcap) will work?
>> Yes, but implementing this feature on securityfs might be not good
>> idea as as James said. If this feature is on procfs or sysfs, it is
>> not necessary to mount securityfs explicitly.
>>
>> Thanks,
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHfD7n+bHCR3gb8jsRAsgcAKDY6qXBR3JV2addHUg5sxyZHJEkDQCfdLOL
> zJlf3T4SQsUNENr3kwR5pr8=
> =v8C5
> -END PGP SIGNATURE-
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2008-01-02 Thread Andrew Morgan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There is also the issue of compiled code which explicitly raises and
lowers capabilities around critical code sections (ie., as they were
intended to be used) is also not well served by this change.

That is, unless the code was compiled with things like CAP_MAC_ADMIN
being #define'd then it won't be able to do things like cap_set_flag()
appropriately.

Cheers

Andrew

KaiGai Kohei wrote:
> Andrew Morgan wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> KaiGai Kohei wrote:
>>> Remaining issues:
>>> - We have to mount securityfs explicitly, or use /etc/fstab.
>>>   It can cause a matter when we want to use this feature on
>>>   very early phase on boot. (like /sbin/init)
>> I'm not altogether clear how you intend this to work.
>>
>> Are you saying that some future version of libcap will require that
>> securityfs be mounted before it (libcap) will work?
> 
> Yes, but implementing this feature on securityfs might be not good
> idea as as James said. If this feature is on procfs or sysfs, it is
> not necessary to mount securityfs explicitly.
> 
> Thanks,
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHfD7n+bHCR3gb8jsRAsgcAKDY6qXBR3JV2addHUg5sxyZHJEkDQCfdLOL
zJlf3T4SQsUNENr3kwR5pr8=
=v8C5
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2008-01-02 Thread James Morris

On Wed, 2 Jan 2008, KaiGai Kohei wrote:

> > Another issue is that securityfs depends on CONFIG_SECURITY, which might be
> > undesirable, given that capabilities are a standard feature.
> 
> We can implement this feature on another pseudo filesystems.
> Do you think what filesystem is the best candidate?
> I prefer procfs or sysfs instead.

Sysfs makes more sense, as this information is system-wide and does not 
relate to specific processes.


-- 
James Morris
<[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2008-01-02 Thread KaiGai Kohei

Andrew Morgan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> KaiGai Kohei wrote:
>> Remaining issues:
>> - We have to mount securityfs explicitly, or use /etc/fstab.
>>   It can cause a matter when we want to use this feature on
>>   very early phase on boot. (like /sbin/init)
> 
> I'm not altogether clear how you intend this to work.
> 
> Are you saying that some future version of libcap will require that
> securityfs be mounted before it (libcap) will work?

Yes, but implementing this feature on securityfs might be not good
idea as as James said. If this feature is on procfs or sysfs, it is
not necessary to mount securityfs explicitly.

Thanks,
-- 
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2008-01-02 Thread KaiGai Kohei


James Morris wrote:

On Fri, 28 Dec 2007, KaiGai Kohei wrote:


Remaining issues:
- We have to mount securityfs explicitly, or use /etc/fstab.
  It can cause a matter when we want to use this feature on
  very early phase on boot. (like /sbin/init)


Why can't early userspace itself mount securityfs?


Hmm,,,
It might be possible as load_policy() doing, if necessary.
Please forget the previous my opinion.

I'm not even sure this is a good idea at all.  Existing capabilities will 
never disappear, and, as with syscalls, it's probably up to userland to 
handle new ones not existing.


When we use libcap built on older kernel for newer kernel, libcap cannot
handle newly added capabilities, because it is not exist on the build 
environment.
Therefore, any available capabilities should be exported dynamically by the 
kernel.


In any case, some more technical issues:


kernel/cap_names.sh generates the body of cap_entries[] array,


This needs to be in the scripts directory.


OK, it will be moved.

The generated header should be made idempotent (#ifdef wrapping), and also 
include a warning that it is automatically generated (identifying the 
script which does so), and that is should not be edited.



+   d_caps = securityfs_create_dir("capability", NULL);
+   if (!d_caps)


Wrong way to check for error -- the function returns an ERR_PTR().


+   f_caps[i] = securityfs_create_file(cap_entries[i].name, 0444,
+  d_caps, &cap_entries[i],
+  &cap_entry_fops);
+   if (!f_caps[i])


Ditto.


OK,

Another issue is that securityfs depends on CONFIG_SECURITY, which might 
be undesirable, given that capabilities are a standard feature.


We can implement this feature on another pseudo filesystems.
Do you think what filesystem is the best candidate?
I prefer procfs or sysfs instead.

Thanks,
--
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2007-12-30 Thread Andrew Morgan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

KaiGai Kohei wrote:
> Remaining issues:
> - We have to mount securityfs explicitly, or use /etc/fstab.
>   It can cause a matter when we want to use this feature on
>   very early phase on boot. (like /sbin/init)

I'm not altogether clear how you intend this to work.

Are you saying that some future version of libcap will require that
securityfs be mounted before it (libcap) will work?

Thanks

Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHd8dE+bHCR3gb8jsRAurnAJ4t5GKckQVj4Xr1JeTjoowUniU2jACgr5V8
3D3zbx5PkrVTRaYay6ZwJSc=
=D2ZM
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2007-12-28 Thread Randy Dunlap

On Fri, 28 Dec 2007 15:16:35 +0900 KaiGai Kohei wrote:

> kernel/cap_names.sh generates the body of cap_entries[] array,
> and it is invoked when we make the kernel.
> 
> Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
> ---
>  Makefile |9 +++
>  cap_names.sh |   21 
>  capability.c |   75 
> +++
>  3 files changed, 105 insertions(+)

Hi,
Please use "diffstat -p 1 -w 70" as suggested in
Documentation/SubmittingPatches so that we can know what
subdirectories those listed file are actually in.

---
~Randy
desserts:  http://www.xenotime.net/linux/recipes/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2007-12-28 Thread James Morris

On Fri, 28 Dec 2007, KaiGai Kohei wrote:

> Remaining issues:
> - We have to mount securityfs explicitly, or use /etc/fstab.
>   It can cause a matter when we want to use this feature on
>   very early phase on boot. (like /sbin/init)

Why can't early userspace itself mount securityfs?

I'm not even sure this is a good idea at all.  Existing capabilities will 
never disappear, and, as with syscalls, it's probably up to userland to 
handle new ones not existing.

In any case, some more technical issues:

> kernel/cap_names.sh generates the body of cap_entries[] array,

This needs to be in the scripts directory.

The generated header should be made idempotent (#ifdef wrapping), and also 
include a warning that it is automatically generated (identifying the 
script which does so), and that is should not be edited.

> + d_caps = securityfs_create_dir("capability", NULL);
> + if (!d_caps)

Wrong way to check for error -- the function returns an ERR_PTR().

> + f_caps[i] = securityfs_create_file(cap_entries[i].name, 0444,
> +d_caps, &cap_entries[i],
> +&cap_entry_fops);
> + if (!f_caps[i])

Ditto.

Another issue is that securityfs depends on CONFIG_SECURITY, which might 
be undesirable, given that capabilities are a standard feature.

- James
-- 
James Morris
<[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2007-12-27 Thread KaiGai Kohei


James Morris wrote:

On Fri, 28 Dec 2007, KaiGai Kohei wrote:


+   snprintf(tmp, sizeof(tmp),
+cap_entry == &cap_entries[0] ? "0x%08x" :  "%u",
+cap_entry->code);
+   len = strlen(tmp);


You don't need to call strlen(), just use scnprintf() and grab the return 
value.


Thanks for your suggestion,

I'll fix it on the next posting.
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2007-12-27 Thread James Morris

On Fri, 28 Dec 2007, KaiGai Kohei wrote:

> + snprintf(tmp, sizeof(tmp),
> +  cap_entry == &cap_entries[0] ? "0x%08x" :  "%u",
> +  cap_entry->code);
> + len = strlen(tmp);

You don't need to call strlen(), just use scnprintf() and grab the return 
value.


- James
-- 
James Morris
<[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2007-12-27 Thread KaiGai Kohei

The attached patch enables to export capability code/name pairs
under /capability of securityfs (revision 2).

Inprovements from the first revison:
- simple_read_from_buffer() is used for read method.
- cap_entries[] array is generated from include/linux/capability.h
  automatically.

Remaining issues:
- We have to mount securityfs explicitly, or use /etc/fstab.
  It can cause a matter when we want to use this feature on
  very early phase on boot. (like /sbin/init)

It was also concerned at the past.
  http://marc.info/?l=linux-kernel&m=112063963623190&w=2

How do you think an idea that the root of securityfs is mounted on
kernel/security of sysfs when it is initialized?
If securityfs got being available when kernel initializing process,
we can always use this feature and the matter will be resolved.

>>> +static struct cap_entry_data cap_entries[] = {
>>> +/* max number of supported format */
>>> +{ _LINUX_CAPABILITY_VERSION,"version" },
>>> +/* max number of capability */
>>> +{ CAP_LAST_CAP,"index" },
>>> +/* list of capabilities */
>>> +{ CAP_CHOWN,"cap_chown" },
>>> +{ CAP_DAC_OVERRIDE,"cap_dac_override" },
>   - snip -
>>> +{ CAP_MAC_OVERRIDE,"cap_mac_override" },
>>> +{ CAP_MAC_ADMIN,"cap_mac_admin" },
>>> +{ -1,NULL},
>>> +};
>>
>> I don't like this duplication with the list in 
>> include/linux/capability.h.
>> Now when a new cap is added, it needs to be
>>
>> 1. added to capability.h
>> 2. swapped as the new CAP_LAST_CAP in capability.h
>> 3. added to this list...
>>
>> Could you integrate the two lists (not sure how offhand), or at least
>> put them in the same place?

kernel/cap_names.sh generates the body of cap_entries[] array,
and it is invoked when we make the kernel.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
---
 Makefile |9 +++
 cap_names.sh |   21 
 capability.c |   75 +++
 3 files changed, 105 insertions(+)

diff --git a/kernel/Makefile b/kernel/Makefile
index dfa9695..45d6034 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -80,3 +80,12 @@ quiet_cmd_ikconfiggz = IKCFG   $@
 targets += config_data.h
 $(obj)/config_data.h: $(obj)/config_data.gz FORCE
$(call if_changed,ikconfiggz)
+
+# cap_names.h contains the code/name pair of capabilities.
+# It is generated using include/linux/capability.h automatically.
+$(obj)/capability.o: $(obj)/cap_names.h
+quiet_cmd_cap_names  = CAPS$@
+  cmd_cap_names  = /bin/sh $(src)/cap_names.sh > $@
+targets += cap_names.h
+$(obj)/cap_names.h: $(src)/cap_names.sh $(src)/../include/linux/capability.h 
FORCE
+   $(call if_changed,cap_names)
diff --git a/kernel/cap_names.sh b/kernel/cap_names.sh
index e69de29..7b2fcfe 100644
--- a/kernel/cap_names.sh
+++ b/kernel/cap_names.sh
@@ -0,0 +1,21 @@
+#!/bin/sh
+
+#
+# generate a cap_names.h file from include/linux/capability.h
+#
+
+BASEDIR=`dirname $0`
+
+cat ${BASEDIR}/../include/linux/capability.h   \
+| egrep '^#define CAP_[A-Z_]+[ ]+[0-9]+$'  \
+| awk 'BEGIN {
+   max_code = -1;
+  }
+  {
+   if ($3 > max_code)
+   max_code = $3;
+   printf("\t{ %s, \"%s\" },\n", $2, tolower($2));
+  }
+  END {
+   printf("\t{ %u, \"index\" },\n", max_code);
+  }'
diff --git a/kernel/capability.c b/kernel/capability.c
index efbd9cd..03a9b62 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -245,3 +245,78 @@ int capable(int cap)
return __capable(current, cap);
 }
 EXPORT_SYMBOL(capable);
+
+/*
+ * capability code/name pairs are exported under /sys/security/capability/
+ */
+struct cap_entry_data {
+   unsigned int code;
+   const char *name;
+};
+
+static struct cap_entry_data cap_entries[] = {
+   /* max number of supported format */
+   { _LINUX_CAPABILITY_VERSION, "version" },
+   /* list of capabilities */
+#include "cap_names.h"
+   { -1, NULL},
+};
+
+static ssize_t cap_entry_read(struct file *file, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+   struct cap_entry_data *cap_entry;
+   char tmp[32];
+   int len;
+
+   cap_entry = file->f_dentry->d_inode->i_private;
+   BUG_ON(!cap_entry);
+
+   snprintf(tmp, sizeof(tmp),
+cap_entry == &cap_entries[0] ? "0x%08x" :  "%u",
+cap_entry->code);
+   len = strlen(tmp);
+
+   return simple_read_from_buffer(buffer, count, ppos, tmp, len);
+}
+
+const struct file_operations cap_entry_fops = {
+   .read = cap_entry_read,
+};
+
+int __init cap_names_export(void)
+{
+   struct dentry *d_caps, *f_caps[ARRAY_SIZE(cap_entries)];
+   int i;
+
+   /* init max number of capability*/
+   cap_entries[1].code = ARRAY_SIZE(cap_entries) - 3;
+
+   d_caps = securityfs_create_di

Re: [PATCH] Exporting capability code/name pairs

2007-12-27 Thread KaiGai Kohei


Serge E. Hallyn wrote:

Quoting KaiGai Kohei ([EMAIL PROTECTED]):

This patch enables to export the code/name pairs of capabilities under
/capability of securityfs.

In the current libcap, it obtains the list of capabilities from header file
on the build environment statically. However, it is not enough portable
between different versions of kernels, because an already built libcap
cannot have knowledge about new added capabilities.

Dynamic collection of code/name pairs of capabilities will resolve this
matter.

But it is not perfect one. I have a bit concern about this patch now.

1. I want to generate cap_entries array from linux/capability.h
   automatically. Is there any good idea?
2. We have to mount securityfs explicitly, or using /etc/fstab.
   It can make a matter when we want to use this features
   in very early boot sequence.

Any comment please.


I like the idea, but

  - snip -

+/*
+ * capability code/name pairs are exported under /sys/security/capability/
+ */
+struct cap_entry_data {
+   unsigned int code;
+   const char *name;
+};
+
+static struct cap_entry_data cap_entries[] = {
+   /* max number of supported format */
+   { _LINUX_CAPABILITY_VERSION,"version" },
+   /* max number of capability */
+   { CAP_LAST_CAP, "index" },
+   /* list of capabilities */
+   { CAP_CHOWN,"cap_chown" },
+   { CAP_DAC_OVERRIDE, "cap_dac_override" },

  - snip -

+   { CAP_MAC_OVERRIDE, "cap_mac_override" },
+   { CAP_MAC_ADMIN,"cap_mac_admin" },
+   { -1,   NULL},
+};


I don't like this duplication with the list in include/linux/capability.h.
Now when a new cap is added, it needs to be

1. added to capability.h
2. swapped as the new CAP_LAST_CAP in capability.h
3. added to this list...

Could you integrate the two lists (not sure how offhand), or at least
put them in the same place?


The following script will generate cap_entries[] array.

cat include/linux/capability.h  \
 | egrep '^#define[ \t]+CAP_[A-Z_]+[ \t]+[0-9]+$'   \
 | awk '{ printf("\t{ %s, \"\" },\n", $2, tolower($2)); }'

It is nice to include the result of this script, like as:

static struct cap_entry_data cap_entries[] = {
/* max number of supported format */
{ _LINUX_CAPABILITY_VERSION,"version" },
/* max number of capability */
{ CAP_LAST_CAP, "index" },
#include "capability_names.h"
{ -1,   NULL },
};

I guess we can put this script on Makefile like as kernel/timeconst.pl doing.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Exporting capability code/name pairs

2007-12-27 Thread Serge E. Hallyn

Quoting KaiGai Kohei ([EMAIL PROTECTED]):
> This patch enables to export the code/name pairs of capabilities under
> /capability of securityfs.
> 
> In the current libcap, it obtains the list of capabilities from header file
> on the build environment statically. However, it is not enough portable
> between different versions of kernels, because an already built libcap
> cannot have knowledge about new added capabilities.
> 
> Dynamic collection of code/name pairs of capabilities will resolve this
> matter.
> 
> But it is not perfect one. I have a bit concern about this patch now.
> 
> 1. I want to generate cap_entries array from linux/capability.h
>automatically. Is there any good idea?
> 2. We have to mount securityfs explicitly, or using /etc/fstab.
>It can make a matter when we want to use this features
>in very early boot sequence.
> 
> Any comment please.

I like the idea, but

> usage:
> ---
> # mount -t securityfs none /sys/kernel/security
> # cd /sys/kernel/security/capability
> # ls
> cap_audit_controlcap_kill  cap_setpcap cap_sys_rawio
> cap_audit_write  cap_lease cap_setuid  cap_sys_resource
> cap_chowncap_linux_immutable   cap_sys_admin   cap_sys_time
> cap_dac_override cap_mknod cap_sys_bootcap_sys_tty_config
> cap_dac_read_search  cap_net_admin cap_sys_chroot  index
> cap_fowner   cap_net_bind_service  cap_sys_module  version
> cap_fsetid   cap_net_broadcast cap_sys_nice
> cap_ipc_lock cap_setfcap   cap_sys_pacct
> cap_ipc_ownercap_setgidcap_sys_ptrace
> # cat cap_audit_write ; echo
> 29
> # cat cap_sys_chroot ; echo
> 18
> # cat version ; echo
> 0x19980330
> # cat index; echo
> 31
> #
> 
> -- 
> OSS Platform Development Division, NEC
> KaiGai Kohei <[EMAIL PROTECTED]>
> 
> Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
> ---
>  capability.c |  127 
> +++
>  1 file changed, 127 insertions(+)
> 
> diff --git a/kernel/capability.c b/kernel/capability.c
> index efbd9cd..5d9bf53 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -245,3 +245,131 @@ int capable(int cap)
>   return __capable(current, cap);
>  }
>  EXPORT_SYMBOL(capable);
> +
> +/*
> + * Capability code/name pair exporting
> + */
> +
> +/*
> + * capability code/name pairs are exported under /sys/security/capability/
> + */
> +struct cap_entry_data {
> + unsigned int code;
> + const char *name;
> +};
> +
> +static struct cap_entry_data cap_entries[] = {
> + /* max number of supported format */
> + { _LINUX_CAPABILITY_VERSION,"version" },
> + /* max number of capability */
> + { CAP_LAST_CAP, "index" },
> + /* list of capabilities */
> + { CAP_CHOWN,"cap_chown" },
> + { CAP_DAC_OVERRIDE, "cap_dac_override" },
> + { CAP_DAC_READ_SEARCH,  "cap_dac_read_search" },
> + { CAP_FOWNER,   "cap_fowner" },
> + { CAP_FSETID,   "cap_fsetid" },
> + { CAP_KILL, "cap_kill" },
> + { CAP_SETGID,   "cap_setgid" },
> + { CAP_SETUID,   "cap_setuid" },
> + { CAP_SETPCAP,  "cap_setpcap" },
> + { CAP_LINUX_IMMUTABLE,  "cap_linux_immutable" },
> + { CAP_NET_BIND_SERVICE, "cap_net_bind_service" },
> + { CAP_NET_BROADCAST,"cap_net_broadcast" },
> + { CAP_NET_ADMIN,"cap_net_admin" },
> + { CAP_NET_RAW,  "cap_net_admin" },
> + { CAP_IPC_LOCK, "cap_ipc_lock" },
> + { CAP_IPC_OWNER,"cap_ipc_owner" },
> + { CAP_SYS_MODULE,   "cap_sys_module" },
> + { CAP_SYS_RAWIO,"cap_sys_rawio" },
> + { CAP_SYS_CHROOT,   "cap_sys_chroot" },
> + { CAP_SYS_PTRACE,   "cap_sys_ptrace" },
> + { CAP_SYS_PACCT,"cap_sys_pacct" },
> + { CAP_SYS_ADMIN,"cap_sys_admin" },
> + { CAP_SYS_BOOT, "cap_sys_boot" },
> + { CAP_SYS_NICE, "cap_sys_nice" },
> + { CAP_SYS_RESOURCE, "cap_sys_resource" },
> + { CAP_SYS_TIME, "cap_sys_time" },
> + { CAP_SYS_TTY_CONFIG,   "cap_sys_tty_config" },
> + { CAP_MKNOD,"cap_mknod" },
> + { CAP_LEASE,"cap_lease" },
> + { CAP_AUDIT_WRITE,  "cap_audit_write" },
> + { CAP_AUDIT_CONTROL,"cap_audit_control" },
> + { CAP_SETFCAP,  "cap_setfcap" },
> + { CAP_MAC_OVERRIDE, "cap_mac_override" },
> + { CAP_MAC_ADMIN,"cap_mac_admin" },
> + { -1,   NULL},
> +};

I don't like this duplication with the list in include/linux/

Re: [PATCH] Exporting capability code/name pairs

2007-12-27 Thread James Morris

On Thu, 27 Dec 2007, KaiGai Kohei wrote:


(Please put the patch above the .sig separator).

+   len = strlen(tmp);
+
+   if (ofs >= len)
+   return 0;
+
+   if (len - ofs < count)
+   count = len - ofs;
+
+   rc = copy_to_user(buffer, tmp + ofs, count);
+   if (rc)
+   return rc;
+
+   *ppos += count;

Use simple_read_from_buffer().



- James
-- 
James Morris
<[EMAIL PROTECTED]>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Exporting capability code/name pairs

2007-12-26 Thread KaiGai Kohei

This patch enables to export the code/name pairs of capabilities under
/capability of securityfs.

In the current libcap, it obtains the list of capabilities from header file
on the build environment statically. However, it is not enough portable
between different versions of kernels, because an already built libcap
cannot have knowledge about new added capabilities.

Dynamic collection of code/name pairs of capabilities will resolve this
matter.

But it is not perfect one. I have a bit concern about this patch now.

1. I want to generate cap_entries array from linux/capability.h
   automatically. Is there any good idea?
2. We have to mount securityfs explicitly, or using /etc/fstab.
   It can make a matter when we want to use this features
   in very early boot sequence.

Any comment please.

usage:
---
# mount -t securityfs none /sys/kernel/security
# cd /sys/kernel/security/capability
# ls
cap_audit_controlcap_kill  cap_setpcap cap_sys_rawio
cap_audit_write  cap_lease cap_setuid  cap_sys_resource
cap_chowncap_linux_immutable   cap_sys_admin   cap_sys_time
cap_dac_override cap_mknod cap_sys_bootcap_sys_tty_config
cap_dac_read_search  cap_net_admin cap_sys_chroot  index
cap_fowner   cap_net_bind_service  cap_sys_module  version
cap_fsetid   cap_net_broadcast cap_sys_nice
cap_ipc_lock cap_setfcap   cap_sys_pacct
cap_ipc_ownercap_setgidcap_sys_ptrace
# cat cap_audit_write ; echo
29
# cat cap_sys_chroot ; echo
18
# cat version ; echo
0x19980330
# cat index; echo
31
#

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
---
 capability.c |  127 +++
 1 file changed, 127 insertions(+)

diff --git a/kernel/capability.c b/kernel/capability.c
index efbd9cd..5d9bf53 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -245,3 +245,131 @@ int capable(int cap)
return __capable(current, cap);
 }
 EXPORT_SYMBOL(capable);
+
+/*
+ * Capability code/name pair exporting
+ */
+
+/*
+ * capability code/name pairs are exported under /sys/security/capability/
+ */
+struct cap_entry_data {
+   unsigned int code;
+   const char *name;
+};
+
+static struct cap_entry_data cap_entries[] = {
+   /* max number of supported format */
+   { _LINUX_CAPABILITY_VERSION,"version" },
+   /* max number of capability */
+   { CAP_LAST_CAP, "index" },
+   /* list of capabilities */
+   { CAP_CHOWN,"cap_chown" },
+   { CAP_DAC_OVERRIDE, "cap_dac_override" },
+   { CAP_DAC_READ_SEARCH,  "cap_dac_read_search" },
+   { CAP_FOWNER,   "cap_fowner" },
+   { CAP_FSETID,   "cap_fsetid" },
+   { CAP_KILL, "cap_kill" },
+   { CAP_SETGID,   "cap_setgid" },
+   { CAP_SETUID,   "cap_setuid" },
+   { CAP_SETPCAP,  "cap_setpcap" },
+   { CAP_LINUX_IMMUTABLE,  "cap_linux_immutable" },
+   { CAP_NET_BIND_SERVICE, "cap_net_bind_service" },
+   { CAP_NET_BROADCAST,"cap_net_broadcast" },
+   { CAP_NET_ADMIN,"cap_net_admin" },
+   { CAP_NET_RAW,  "cap_net_admin" },
+   { CAP_IPC_LOCK, "cap_ipc_lock" },
+   { CAP_IPC_OWNER,"cap_ipc_owner" },
+   { CAP_SYS_MODULE,   "cap_sys_module" },
+   { CAP_SYS_RAWIO,"cap_sys_rawio" },
+   { CAP_SYS_CHROOT,   "cap_sys_chroot" },
+   { CAP_SYS_PTRACE,   "cap_sys_ptrace" },
+   { CAP_SYS_PACCT,"cap_sys_pacct" },
+   { CAP_SYS_ADMIN,"cap_sys_admin" },
+   { CAP_SYS_BOOT, "cap_sys_boot" },
+   { CAP_SYS_NICE, "cap_sys_nice" },
+   { CAP_SYS_RESOURCE, "cap_sys_resource" },
+   { CAP_SYS_TIME, "cap_sys_time" },
+   { CAP_SYS_TTY_CONFIG,   "cap_sys_tty_config" },
+   { CAP_MKNOD,"cap_mknod" },
+   { CAP_LEASE,"cap_lease" },
+   { CAP_AUDIT_WRITE,  "cap_audit_write" },
+   { CAP_AUDIT_CONTROL,"cap_audit_control" },
+   { CAP_SETFCAP,  "cap_setfcap" },
+   { CAP_MAC_OVERRIDE, "cap_mac_override" },
+   { CAP_MAC_ADMIN,"cap_mac_admin" },
+   { -1,   NULL},
+};
+
+static ssize_t cap_entry_read(struct file *file, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+   struct cap_entry_data *cap_entry;
+   size_t len, ofs = *ppos;
+   char tmp[32];
+   int rc;
+
+   cap_entry = file->

43 matches

Mail list logo