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
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
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;
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
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
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
/sys/kernel/capability/codes:
0 10 12 14
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/
-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
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 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 intend
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 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
27 matches
Mail list logo
