[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <480EE755.4090202@ak.jp.nec.com>
Date: Wed, 23 Apr 2008 16:37:57 +0900
From: KaiGai Kohei <kaigai@...jp.nec.com>
To: Alexey Dobriyan <adobriyan@...il.com>
CC: greg@...ah.com, morgan@...nel.org, serue@...ibm.com,
chrisw@...s-sol.org, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)
Alexey Dobriyan wrote:
> On Wed, Apr 23, 2008 at 09:38:31AM +0900, KaiGai Kohei wrote:
>> Alexey Dobriyan wrote:
>>> On Tue, Apr 22, 2008 at 08:12:15PM +0900, KaiGai Kohei wrote:
>>>> $ 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 26 28 3 31 33 5 7 9
>>>>
>>>> /sys/kernel/capability/names:
>>>> cap_audit_control cap_kill cap_net_raw cap_sys_nice
>>>> cap_audit_write cap_lease cap_setfcap cap_sys_pacct
>>>> cap_chown cap_linux_immutable cap_setgid cap_sys_ptrace
>>>> cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio
>>>> cap_dac_read_search cap_mac_override cap_setuid
>>>> cap_sys_resource
>>>> cap_fowner cap_mknod cap_sys_admin cap_sys_time
>>>> cap_fsetid cap_net_admin cap_sys_boot
>>>> cap_sys_tty_config
>>>> cap_ipc_lock cap_net_bind_service cap_sys_chroot
>>>> cap_ipc_owner cap_net_broadcast cap_sys_module
>>>> $ cat /sys/kernel/capability/names/cap_sys_pacct
>>>> 20
>>>> $ cat /sys/kernel/capability/codes/16
>>>> cap_sys_module
>>> This is amazing amount of bloat for such conceptually simple feature!
>>> Below is /proc/capabilities ,
>>> a) without all memory eaten by sysfs files and directories,
>>> generated on the fly
>>> b) with capability names matching the ones in manpages
>>> c) nicely formatted
>>> e) with whole-whooping 2 lines of protection from fool
>>> (including helpful directions)
>>> Proposed regexp of course will incorrectly match someday
>>> If this file will be used often, I can even make whole its content
>>> become generated at compile time and then put into buffers
>>> with 1 (one) seq_puts()!
>> I had suggested a similar idea previously, but it could not be supported
>> because it requires to scan whole of /proc/capabilities at first.
>
> You claim that libcap people can't or don't want to parse such file?
Yes,
In the previous discussion, it was undesirable idea to parse a file
to obtain a new/unknown capability name/code pair, because it tends
to have bigger number and appears at the tail.
(If my brain memories it correctly.)
> 0 CAP_CHOWN
> 1 CAP_DAC_OVERRIDE
> 2 CAP_DAC_READ_SEARCH
> 3 CAP_FOWNER
> 4 CAP_FSETID
> 5 CAP_KILL
> 6 CAP_SETGID
> 7 CAP_SETUID
> 8 CAP_SETPCAP
> 9 CAP_LINUX_IMMUTABLE
> 10 CAP_NET_BIND_SERVICE
> 11 CAP_NET_BROADCAST
> 12 CAP_NET_ADMIN
> 13 CAP_NET_RAW
> 14 CAP_IPC_LOCK
> 15 CAP_IPC_OWNER
> 16 CAP_SYS_MODULE
> 17 CAP_SYS_RAWIO
> 18 CAP_SYS_CHROOT
> 19 CAP_SYS_PTRACE
> 20 CAP_SYS_PACCT
> 21 CAP_SYS_ADMIN
> 22 CAP_SYS_BOOT
> 23 CAP_SYS_NICE
> 24 CAP_SYS_RESOURCE
> 25 CAP_SYS_TIME
> 26 CAP_SYS_TTY_CONFIG
> 27 CAP_MKNOD
> 28 CAP_LEASE
> 29 CAP_AUDIT_WRITE
> 30 CAP_AUDIT_CONTROL
> 31 CAP_SETFCAP
> 32 CAP_MAC_OVERRIDE
> 33 CAP_MAC_ADMIN
>
> That's what you claim? Do I undestand you correctly?
Yes, but I don't *oppose* your approach. :)
BTW, I think "version" info should be included as follows:
0x20071026 vesion
0 cap_chown
1 cap_dac_override
: :
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@...jp.nec.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists