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
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
[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
[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
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
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. :-(
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
[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
[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
[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
>> 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
[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
[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
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
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
>> 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 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
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
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
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
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
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 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
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
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
>> 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?
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
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
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 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
32 matches
Mail list logo
