login
Search
The following three patches enables to export code/name pairs of capabilities the running kernel supports, and add a documentation and samples to use this feature. [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can refer this information to identify what entry is accessed. It makes easier to share a single method implementation with several similar entries, like ones to export the list of capabilities the running kernel supports. [PATCH 2/3] exporting capability name/code pairs This patch enables to export code/name pairs of capabilities the running kernel supported. A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN at 2.6.25. However, we have no interface to disclose what capabilities are supported on the running kernel. Thus, we have to maintain libcap version in appropriate one synchronously. This patch enables libcap to collect the list of capabilities at run time, and provide them for users. It helps to improve portability of library. It exports these information as regular files under /sys/kernel/capability. The numeric node exports its name, the symbolic node exports its code. [PATCH 3/3] a new example to use kobject/kobj_attribute This patch can provide a new exmple to use kobject and attribute. The _show() and _store() method can refer/store the private data field of kobj_attribute structure to know what entries are accessed by users. It will make easier to share a single _show()/_store() method with several entries. o changes from the previous version - add a short description at Documentation/kobject.txt, to use private member within kobj_attribute. - "supported" is replaced with "supports" at sysfs-kernel-capability. - "$(src)/../" is replaced with "$(srctree)/" at security/Makefile - The private member is casted to long, when it stores integer ...
[PATCH 1/3] add a private data field within kobj_attribute structure.
This patch add a private data field, declared as void *, within kobj_attribute
structure. The _show() and _store() method in the sysfs attribute entries can
refer this information to identify what entry is accessed.
It makes easier to share a single method implementation with several similar
entries, like ones to export the list of capabilities the running kernel
supports.
Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
Documentation/kobject.txt | 6 ++++++
include/linux/kobject.h | 1 +
include/linux/sysfs.h | 7 +++++++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index bf3256e..efa5d71 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created
with the kobject_create_and_add(), can be of type kobj_attribute, so no
special custom attribute is needed to be created.
+The simple kobj_attribute is prototyped at include/linux/kobject.h, and can
+contain your own show()/store() method and private data.
+When an attribute is accessed, these methods are invoked with kobject,
+kobj_attribute and read/write buffer. The method can refer the private data
+via given kobj_attribute, to show/store itself in the text representation.
+
See the example module, samples/kobject/kobject-example.c for an
implementation of a simple kobject and attributes.
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index caa3f41..57d5bf1 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -130,6 +130,7 @@ struct kobj_attribute {
char *buf);
ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count);
+ void *data; /* a private field */
};
extern struct sysfs_ops kobj_sysfs_ops;
diff --git a/include/linux/sysfs.h ...That's good, but you didn't modify the sample/kobject/ file to use the new void pointer, instead of the strcmp() call. thanks, greg k-h --
The 3/3 of patches updates sample/kobject to use the new void pointer. Do you want it to replace strcmp() examples completly? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
Doh, I totally missed that one, very sorry. I'll be glad to take patches 1 and 3 in my tree, if you want me to. thanks, greg k-h --
I want them to be upstreamed, no need to say. BTW, how do you think about the second patch which provides the most practical feature? Thanks for your reviewing. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
I personally have no opinion on this patch, sorry. thanks, greg k-h --
OK, I'm an idiot, so I re-read this several times, and looked at patch 3/3 that added the sample code, and I'm still confoozled. Who creates/destroys/manages this "read/write buffer", and/or how does the method know how large a buffer is available, so (for example) it can use the strn* versions of string functions to be sure not to run off the end? Does this buffer have any lifetime rules attached to it?
This "read/write buffer" is managed by sysfs filesystem. Sysfs is invoked via kernel VFS subsystem, when user calls read(2) or write(2). In the read(2) case, sysfs_read_file() is invoked, allocates a page for buffer, and calls the show() method to generate the containts of this pseudo file entry. Therefore, show() and store() method does not need to manage this buffer. When store() method is invoked with data from userspace, sysfs terminate it with '\0' implicitly. The size of buffer is also limited to PAGE_SIZE implicitly. Can you make it clear? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
[PATCH 2/3] exporting capability name/code pairs This patch enables to export code/name pairs of capabilities the running kernel supported. A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN at 2.6.25. However, we have no interface to disclose what capabilities are supported on the running kernel. Thus, we have to maintain libcap version in appropriate one synchronously. This patch enables libcap to collect the list of capabilities at run time, and provide them for users. It helps to improve portability of library. It exports these information as regular files under /sys/kernel/capability. The numeric node exports its name, the symbolic node exports its code. Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> -- Documentation/ABI/testing/sysfs-kernel-capability | 23 +++++ scripts/mkcapnames.sh | 44 +++++++++ security/Makefile | 9 ++ security/commoncap.c | 99 +++++++++++++++++++++ 4 files changed, 175 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-kernel-capability b/Documentation/ABI/testing/sysfs-kernel-capability index e69de29..d4a14e7 100644 --- a/Documentation/ABI/testing/sysfs-kernel-capability +++ b/Documentation/ABI/testing/sysfs-kernel-capability @@ -0,0 +1,23 @@ +What: /sys/kernel/capability +Date: Feb 2008 +Contact: KaiGai Kohei <kaigai@ak.jp.nec.com> +Description: + The entries under /sys/kernel/capability are used to export + the list of capabilities the running kernel supports. + + - /sys/kernel/capability/version + returns the most preferable version number for the + running kernel. + e.g) $ cat /sys/kernel/capability/version + 0x20071026 + + - /sys/kernel/capability/code/<numerical representation> + returns its symbolic representation, on reading. + e.g) $ cat /sys/kernel/capability/codes/30 + cap_audit_control + + - /sys/kernel/capability/name/<symbolic ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Acked-by: Andrew G. Morgan <morgan@kernel.org> Tested-by: Andrew G. Morgan <morgan@kernel.org> Cheers Andrew Kohei KaiGai wrote: | [PATCH 2/3] exporting capability name/code pairs | | This patch enables to export code/name pairs of capabilities the running | kernel supported. | | A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN | at 2.6.25. However, we have no interface to disclose what capabilities | are supported on the running kernel. Thus, we have to maintain libcap | version in appropriate one synchronously. | | This patch enables libcap to collect the list of capabilities at run time, | and provide them for users. It helps to improve portability of library. | | It exports these information as regular files under /sys/kernel/capability. | The numeric node exports its name, the symbolic node exports its code. | | Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> | -- | Documentation/ABI/testing/sysfs-kernel-capability | 23 +++++ | scripts/mkcapnames.sh | 44 +++++++++ | security/Makefile | 9 ++ | security/commoncap.c | 99 +++++++++++++++++++++ | 4 files changed, 175 insertions(+), 0 deletions(-) | | diff --git a/Documentation/ABI/testing/sysfs-kernel-capability b/Documentation/ABI/testing/sysfs-kernel-capability | index e69de29..d4a14e7 100644 | --- a/Documentation/ABI/testing/sysfs-kernel-capability | +++ b/Documentation/ABI/testing/sysfs-kernel-capability | @@ -0,0 +1,23 @@ | +What: /sys/kernel/capability | +Date: Feb 2008 | +Contact: KaiGai Kohei <kaigai@ak.jp.nec.com> | +Description: | + The entries under /sys/kernel/capability are used to export | + the list of capabilities the running kernel supports. | + | + - /sys/kernel/capability/version | + returns the most preferable version number for the | + running kernel. | + e.g) $ cat /sys/kernel/capability/version | ...
Also Acked-by: Serge Hallyn <serue@us.ibm.com> Tested-by: Serge Hallyn <serue@us.ibm.com> thanks, -serge --
Who can pick up this patch to the upstreamed tree? It's unclear for me, because no one is explicitly listed as a maintainer of capabilities.... # I believe we need no more technical discussion any more # in this feature. Sorry, I made an oversight. However, I'm not an expert of kernel makefiles. It follows the bottom of kernel/Makefile as an example. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
If the security maintainer (Chris Wright) signs off on it, I'll be glad to take this through my tree as it does need the kobject changes to work properly. thanks, greg k-h --
[PATCH 3/3] a new example to use kobject/kobj_attribute
This patch can provide a new exmple to use kobject and attribute.
The _show() and _store() method can refer/store the private data field of
kobj_attribute structure to know what entries are accessed by users.
It will make easier to share a single _show()/_store() method with several
entries.
Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
samples/kobject/kobject-example.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/samples/kobject/kobject-example.c b/samples/kobject/kobject-example.c
index 08d0d3f..5486a14 100644
--- a/samples/kobject/kobject-example.c
+++ b/samples/kobject/kobject-example.c
@@ -77,6 +77,35 @@ static struct kobj_attribute baz_attribute =
static struct kobj_attribute bar_attribute =
__ATTR(bar, 0666, b_show, b_store);
+/*
+ * You can store a private data within 'data' field of kobj_attribute.
+ * It enables to share a single _show() or _store() method with several
+ * entries.
+ */
+static ssize_t integer_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return scnprintf(buf, PAGE_SIZE, "%ld\n", (long) attr->data);
+}
+
+static ssize_t integer_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ long code;
+
+ sscanf(buf, "%ld", &code);
+ attr->data = (void *) code;
+ return count;
+}
+
+static struct kobj_attribute hoge_attribute =
+ __ATTR_DATA(hoge, 0666, integer_show, integer_store, (long) 123);
+static struct kobj_attribute piyo_attribute =
+ __ATTR_DATA(piyo, 0666, integer_show, integer_store, (long) 456);
+static struct kobj_attribute fuga_attribute =
+ __ATTR_DATA(fuga, 0444, integer_show, NULL, (long) 789);
/*
* Create a group of attributes so that we can create and destory them all
@@ -86,6 +115,9 @@ static struct attribute *attrs[] = {
&foo_attribute.attr,
&baz_attribute.attr,
...The following three patches enables to export code/name pairs of capabilities the running kernel supports, and add a documentation and samples to use this feature. It was too late for 2.6.25 merge window, so I submit them again for the next development cycle. [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can refer this information to identify what entry is accessed. It makes easier to share a single method implementation with several similar entries, like ones to export the list of capabilities the running kernel supports. [PATCH 2/3] exporting capability name/code pairs This patch enables to export code/name pairs of capabilities the running kernel supported. A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN at 2.6.25. However, we have no interface to disclose what capabilities are supported on the running kernel. Thus, we have to maintain libcap version in appropriate one synchronously. This patch enables libcap to collect the list of capabilities at run time, and provide them for users. It helps to improve portability of library. It exports these information as regular files under /sys/kernel/capability. The numeric node exports its name, the symbolic node exports its code. [PATCH 3/3] a new example to use kobject/kobj_attribute This patch can provide a new exmple to use kobject and attribute. The _show() and _store() method can refer/store the private data field of kobj_attribute structure to know what entries are accessed by users. It will make easier to share a single _show()/_store() method with several entries. -------------- Example of execution: [kaigai@saba ~]$ uname -r 2.6.25.capnames [kaigai@saba ~]$ ls -R /sys/kernel/capability/ /sys/kernel/capability/: codes names version /sys/kernel/capability/codes: 0 10 12 14 16 18 2 21 23 25 27 ...
[PATCH 3/3] a new example to use kobject/kobj_attribute
This patch can provide a new exmple to use kobject and attribute.
The _show() and _store() method can refer/store the private data field of
kobj_attribute structure to know what entries are accessed by users.
It will make easier to share a single _show()/_store() method with several
entries.
Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
samples/kobject/kobject-example.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/samples/kobject/kobject-example.c b/samples/kobject/kobject-example.c
index 08d0d3f..5486a14 100644
--- a/samples/kobject/kobject-example.c
+++ b/samples/kobject/kobject-example.c
@@ -77,6 +77,35 @@ static struct kobj_attribute baz_attribute =
static struct kobj_attribute bar_attribute =
__ATTR(bar, 0666, b_show, b_store);
+/*
+ * You can store a private data within 'data' field of kobj_attribute.
+ * It enables to share a single _show() or _store() method with several
+ * entries.
+ */
+static ssize_t integer_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return scnprintf(buf, PAGE_SIZE, "%ld\n", (long) attr->data);
+}
+
+static ssize_t integer_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ long code;
+
+ sscanf(buf, "%ld", &code);
+ attr->data = (void *) code;
+ return count;
+}
+
+static struct kobj_attribute hoge_attribute =
+ __ATTR_DATA(hoge, 0666, integer_show, integer_store, (long) 123);
+static struct kobj_attribute piyo_attribute =
+ __ATTR_DATA(piyo, 0666, integer_show, integer_store, (long) 456);
+static struct kobj_attribute fuga_attribute =
+ __ATTR_DATA(fuga, 0444, integer_show, NULL, (long) 789);
/*
* Create a group of attributes so that we can create and destory them all
@@ -86,6 +115,9 @@ static struct attribute *attrs[] = {
&foo_attribute.attr,
&baz_attribute.attr,
...[PATCH 2/3] exporting capability name/code pairs
This patch enables to export code/name pairs of capabilities the running
kernel supported.
A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
at 2.6.25. However, we have no interface to disclose what capabilities
are supported on the running kernel. Thus, we have to maintain libcap
version in appropriate one synchronously.
This patch enables libcap to collect the list of capabilities at run time,
and provide them for users. It helps to improve portability of library.
It exports these information as regular files under /sys/kernel/capability.
The numeric node exports its name, the symbolic node exports its code.
Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
scripts/mkcapnames.sh | 44 ++++++++++++++++++++++
security/Makefile | 9 ++++
security/commoncap.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 152 insertions(+), 0 deletions(-)
diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh
index e69de29..5d36d52 100644
--- a/scripts/mkcapnames.sh
+++ b/scripts/mkcapnames.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+#
+# generate a cap_names.h file from include/linux/capability.h
+#
+
+CAPHEAD="`dirname $0`/../include/linux/capability.h"
+REGEXP='^#define CAP_[A-Z_]+[ ]+[0-9]+$'
+NUMCAP=`cat "$CAPHEAD" | egrep -c "$REGEXP"`
+
+echo '#ifndef CAP_NAMES_H'
+echo '#define CAP_NAMES_H'
+echo
+echo '/*'
+echo ' * Do NOT edit this file directly.'
+echo ' * This file is generated from include/linux/capability.h automatically'
+echo ' */'
+echo
+echo '#if !defined(SYSFS_CAP_NAME_ENTRY) || !defined(SYSFS_CAP_CODE_ENTRY)'
+echo '#error cap_names.h should be included from security/capability.c'
+echo '#else'
+echo "#if $NUMCAP != CAP_LAST_CAP + 1"
+echo '#error mkcapnames.sh cannot collect capabilities correctly'
+echo '#else'
+cat "$CAPHEAD" | egrep "$REGEXP" \
+ | awk '{ printf("SYSFS_CAP_NAME_ENTRY(%s,%s);\n", tolower($2), $2); }'
+echo
+echo 'static ...[PATCH 1/3] add a private data field within kobj_attribute structure.
This patch add a private data field, declared as void *, within kobj_attribute
structure. The _show() and _store() method in the sysfs attribute entries can
refer this information to identify what entry is accessed.
It makes easier to share a single method implementation with several similar
entries, like ones to export the list of capabilities the running kernel
supports.
Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
Documentation/kobject.txt | 6 ++++++
include/linux/kobject.h | 1 +
include/linux/sysfs.h | 7 +++++++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index bf3256e..efa5d71 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created
with the kobject_create_and_add(), can be of type kobj_attribute, so no
special custom attribute is needed to be created.
+The simple kobj_attribute is prototyped at include/linux/kobject.h, and can
+contain your own show()/store() method and private data.
+When an attribute is accessed, these methods are invoked with kobject,
+kobj_attribute and read/write buffer. The method can refer the private data
+via given kobj_attribute, to show/store itself in the text representation.
+
See the example module, samples/kobject/kobject-example.c for an
implementation of a simple kobject and attributes.
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index caa3f41..57d5bf1 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -130,6 +130,7 @@ struct kobj_attribute {
char *buf);
ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count);
+ void *data; /* a private field */
};
extern struct sysfs_ops kobj_sysfs_ops;
diff --git a/include/linux/sysfs.h ...This is amazing amount of bloat for such conceptually simple feature!
Below is /proc/capabilities ,
a) without all memory eaten by sysfs files and directories,
generated on the fly
b) with capability names matching the ones in manpages
c) nicely formatted
e) with whole-whooping 2 lines of protection from fool
(including helpful directions)
Proposed regexp of course will incorrectly match someday
If this file will be used often, I can even make whole its content
become generated at compile time and then put into buffers
with 1 (one) seq_puts()!
Alexey "0 CAP_CHOWN
1 CAP_DAC_OVERRIDE
2 CAP_DAC_READ_SEARCH
3 CAP_FOWNER
4 CAP_FSETID
5 CAP_KILL
6 CAP_SETGID
7 CAP_SETUID
8 CAP_SETPCAP
9 CAP_LINUX_IMMUTABLE
10 CAP_NET_BIND_SERVICE
11 CAP_NET_BROADCAST
12 CAP_NET_ADMIN
13 CAP_NET_RAW
14 CAP_IPC_LOCK
15 CAP_IPC_OWNER
16 CAP_SYS_MODULE
17 CAP_SYS_RAWIO
18 CAP_SYS_CHROOT
19 CAP_SYS_PTRACE
20 CAP_SYS_PACCT
21 CAP_SYS_ADMIN
22 CAP_SYS_BOOT
23 CAP_SYS_NICE
24 CAP_SYS_RESOURCE
25 CAP_SYS_TIME
26 CAP_SYS_TTY_CONFIG
27 CAP_MKNOD
28 CAP_LEASE
29 CAP_AUDIT_WRITE
30 CAP_AUDIT_CONTROL
31 CAP_SETFCAP
32 CAP_MAC_OVERRIDE
33 CAP_MAC_ADMIN" Dobriyan
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -19,6 +19,8 @@
#include <linux/swap.h>
#include <linux/skbuff.h>
#include <linux/netlink.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
#include <linux/ptrace.h>
#include <linux/xattr.h>
#include <linux/hugetlb.h>
@@ -597,3 +599,81 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages)
return __vm_enough_memory(mm, pages, cap_sys_admin);
}
+#ifdef CONFIG_PROC_FS
+static const struct {
+ int val;
+ const char *str;
+} proc_cap[] = {
+#define _(cap) { .val = cap, .str = #cap ...I had suggested a similar idea previously, but it could not be supported because it requires to scan whole of /proc/capabilities at first. It should be generated automatically. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
You claim that libcap people can't or don't want to parse such file? 0 CAP_CHOWN 1 CAP_DAC_OVERRIDE 2 CAP_DAC_READ_SEARCH 3 CAP_FOWNER 4 CAP_FSETID 5 CAP_KILL 6 CAP_SETGID 7 CAP_SETUID 8 CAP_SETPCAP 9 CAP_LINUX_IMMUTABLE 10 CAP_NET_BIND_SERVICE 11 CAP_NET_BROADCAST 12 CAP_NET_ADMIN 13 CAP_NET_RAW 14 CAP_IPC_LOCK 15 CAP_IPC_OWNER 16 CAP_SYS_MODULE 17 CAP_SYS_RAWIO 18 CAP_SYS_CHROOT 19 CAP_SYS_PTRACE 20 CAP_SYS_PACCT 21 CAP_SYS_ADMIN 22 CAP_SYS_BOOT 23 CAP_SYS_NICE 24 CAP_SYS_RESOURCE 25 CAP_SYS_TIME 26 CAP_SYS_TTY_CONFIG 27 CAP_MKNOD 28 CAP_LEASE 29 CAP_AUDIT_WRITE 30 CAP_AUDIT_CONTROL 31 CAP_SETFCAP 32 CAP_MAC_OVERRIDE 33 CAP_MAC_ADMIN That's what you claim? Do I undestand you correctly? --
Yes, In the previous discussion, it was undesirable idea to parse a file to obtain a new/unknown capability name/code pair, because it tends to have bigger number and appears at the tail. Yes, but I don't *oppose* your approach. :) BTW, I think "version" info should be included as follows: 0x20071026 vesion 0 cap_chown 1 cap_dac_override : : Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
It shouldn't. You can do capget(42, ...);, get EINVAL and current version written back. Wrap this in libcap if needed. --
libcap is the primary user of the facility to export capability name/code pairs. I think obviously libcap should wrap this version info and hide it from applications/users. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
I do not understand why this is necessary. The capability bits are an ABI that shouldn't change in a non-backward compat way (i.e. only additions). We typically don't export strings <-> number conversions for constants. I know you've explained this a few times before, but it still seems to me like a userspace only problem. What can userspace do with a capability it does not know about? thanks, -chris --
When we run a userspace utility on the latest kernel, it has to be compiled with kernel-headers which have same capability set at least. If installed userspace utility does not support newly added capabilities, it requires users to rebuild their utilities when they update the kernel. Typically, kernel developer faces this kind of version mismatching. When they boots their kernel with new capabilities, it also requires to rebuild libcap. Then, they have to revert it, when they boots with normal kernel. If libcap can know what capabilities are supported on the running kernel automatically, it does not need users to rebuild libcap concurrently. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
Chris, what is the status of the patch? -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
...libcap can do anything meaningful here with capabilities it doesn't know about? This interface is already versioned, what is wrong is old cap version on new kernel (clearly new cap version on old kernel would have to fall back to older cap version)? thanks, -chris --
The versioning info is just a hint in this case. The major purpose of this patch is to save steps of maintainance. When we tries to run a application using a new capability provided by the latest kernel, we have to rebuild libcap to follow kernel updates. If we can obtain an information what capabilities are supported in the running kernel, we don't need to rebuild libcap for the latest kernel everytime. For example, we got CAP_MAC_ADMIN at 2.6.25. If an application tries to use it, we have to replace libcap for 2.6.24 by libcap for 2.6.25. Although, we don't get any updates in libcap. :-( In addition, I noticed it will be usefull for applications which have a possibility to use arbitary number of capabilities, like busybox if setcap/getcap stuff is ported. (IMO, we should not use libcap for busybox, because its first priority is to reduce binary size, limited to minimun functionalities.) Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 KaiGai Kohei wrote: | For example, we got CAP_MAC_ADMIN at 2.6.25. If an application tries to | use it, we have to replace libcap for 2.6.24 by libcap for 2.6.25. | Although, we don't get any updates in libcap. :-( I'm not sure what you mean here. I think you will find that this particular capability was supported in libcap 2.03. Current is 2.09. Also, having Ack'd your proposed kernel patch, I speculatively included support for it in libcap-2.08. I will, of course, remove this support if the kernel doesn't adopt your change - or picks a different strategy... As it is, the patched kernel works nicely. :-) http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/ Cheers Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFIK86y+bHCR3gb8jsRAnV4AJ9gCaTwfKs8r7KX4DFixT84A5buOQCYlbaX mnMx52Yt2pRcLAXTOXElLA== =31Cy -----END PGP SIGNATURE----- --
What I wanted to say is that we have to update/rebuild/reinstall userland packages using arbitary number of capabilities (like libcap) whenever the newer kernel adds a new capability, however, is it really necessary? -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --
