>> All that being said, the friendliness factor of this is somewhat
>> undeniable, and so I can see why folk might want it in the kernel
>> anyway. If so, would it possible to move this code into
>> security/capability.c and not in the main kernel per-se - protected with
>> a configuration option?
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
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
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
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
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
i
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 c
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 n
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 supp
>> 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 patc
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
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
[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
[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 co
>> 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
[2/3] Exporting capability code/name 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 runn
[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
[3/3] A new example to use kobject/kobj_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 accessed by users.
It will make easier to share a
Andrew G. Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
I've just tried to build this with a separate obj tree: make O=/path.../
~ the build failed as follows:
~ CC security/dummy.o
~ CC security/inode.o
~ CAPSsecurity/cap_names.h
/bin/sh: security/../scr
Serge E. Hallyn wrote:
Quoting Kohei KaiGai ([EMAIL PROTECTED]):
All that being said, the friendliness factor of this is somewhat
undeniable, and so I can see why folk might want it in the kernel
anyway. If so, would it possible to move this code into
security/capability.c and not in the main
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 capabili
Li Zefan wrote:
>> [2/3] Exporting capability code/name pairs
>>
>> This patch enables to export code/name pairs of capabilities the running
>> kernel supported.
>>
>
> supported or supports ?
It seems to me "supports" is more appropriate one.
The original one might mention legacy versions. :-(
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
[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 eas
[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 th
[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 si
Greg KH wrote:
On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote:
[PATCH 1/3] add a private data field within kobj_attribute structure.
This patch add a private data field, declared as void *, within kobj_attribute
structure. The _show() and _store() method in the sysfs attribute
Greg KH wrote:
On Mon, Feb 25, 2008 at 03:57:44PM +0900, Kohei KaiGai wrote:
Greg KH wrote:
On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote:
[PATCH 1/3] add a private data field within kobj_attribute structure.
This patch add a private data field, declared as void *, within
We can apply this patch to libcap.
This patch enables setcap command to print the list
of capabilities running kernel supported, if the kernel
exports capability code/name pairs.
It is useful to confirm the name of capability when setting.
Thanks,
Signed-off-by: KaiGai Kohei <[EMAIL PROTECTE
We can apply this patch to libcap.
It enables to obtain the list of capabilities running kernel
supported dynamically, from /sys/kernel/capability.
When we use libcap with this patch on the previous kernel,
it apply static list of capabilities instead.
Thanks,
Signed-off-by: KaiGai Kohei <[E
We can apply this patch to kernel-2.6.24.
It enables to export code/name pairs of capabilities
at /sys/kernel/capability/, as follows:
[EMAIL PROTECTED] ~]# ls /sys/kernel/capability/
cap_audit_controlcap_kill cap_setgid cap_sys_ptrace
cap_audit_write cap_lease
Andrew,
Thanks for your comments.
Andrew G. Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
While this is cute :-), I guess I'm still not all that convinced that
this is needed.
libcap already had some (admittedly not quite working) support for
numeric values of capabilit
32 matches
Mail list logo
