>> 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
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
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
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.
>
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 pa
>> 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
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 mad
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 run
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 newe
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
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
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");
> > >> +
>
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
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
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/kerne
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/c
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_C
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/code
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/"
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 o
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
-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 o
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
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 file
> 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 th
-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 li
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 cand
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
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 security
-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 inten
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
>
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 eve
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 re
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
-
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 iss
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
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
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);
+
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 al
43 matches
Mail list logo
