>> 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
[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
[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
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.
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
>> 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
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
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
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
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
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
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.
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
[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
[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
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
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
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
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
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
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
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
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
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
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
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.
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;
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
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
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
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
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
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
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
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
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
> >>
>
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
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/
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
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
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
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
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
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
-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
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
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
> 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
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
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
-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
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
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)
>
>
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
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
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
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?
-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
-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
-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
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
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
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
James Morris wrote:
On Fri, 28 Dec 2007, KaiGai Kohei wrote:
+ snprintf(tmp, sizeof(tmp),
+cap_entry == _entries[0] ? "0x%08x" : "%u",
+cap_entry->code);
+ len = strlen(tmp);
You don't need to call strlen(), just use scnprintf() and grab the
On Fri, 28 Dec 2007, KaiGai Kohei wrote:
> + snprintf(tmp, sizeof(tmp),
> + cap_entry == _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
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);
+
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);
+
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
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
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
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
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
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
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
85 matches
Mail list logo
