Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

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@ak.jp.nec.com>