public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: greg@kroah.com, morgan@kernel.org, serue@us.ibm.com,
	chrisw@sous-sol.org, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)
Date: Wed, 14 May 2008 09:34:20 +0900	[thread overview]
Message-ID: <482A338C.6040907@ak.jp.nec.com> (raw)
In-Reply-To: <20080513221227.GA7164@martell.zuzino.mipt.ru>

Alexey Dobriyan wrote:
>>> 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
>>   :    :
> 
> It shouldn't. You can do capget(42, ...);, get EINVAL and current
> version written back.
> 
> Wrap this in libcap if needed.

libcap is the primary user of the facility to export capability
name/code pairs. I think obviously libcap should wrap this version
info and hide it from applications/users.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

  reply	other threads:[~2008-05-14  0:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25  6:06 [PATCH 0/3] exporting capability name/code pairs (final#2) Kohei KaiGai
2008-02-25  6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai
2008-02-25  6:51   ` Greg KH
2008-02-25  6:57     ` Kohei KaiGai
2008-02-25  7:47       ` Greg KH
2008-02-25 10:04         ` Kohei KaiGai
2008-02-26 20:09           ` Greg KH
2008-02-28  5:49   ` Valdis.Kletnieks
2008-03-03  4:42     ` Kohei KaiGai
2008-02-25  6:10 ` [PATCH 2/3] exporting capability name/code pairs (final#2) Kohei KaiGai
2008-02-26 14:55   ` Andrew G. Morgan
2008-02-26 20:58     ` Serge E. Hallyn
2008-03-07  4:30       ` Kohei KaiGai
2008-03-07  4:53         ` Greg KH
2008-02-25  6:10 ` [PATCH 3/3] a new example to use kobject/kobj_attribute (final#2) Kohei KaiGai
2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei
2008-04-22 11:17   ` [PATCH 1/3] add a private data field within kobj_attribute structure KaiGai Kohei
2008-04-22 11:18   ` [PATCH 2/3] exporting capability name/code pairs KaiGai Kohei
2008-04-22 11:18   ` [PATCH 3/3] a new example to use kobject/kobj_attribute KaiGai Kohei
2008-04-22 19:29   ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) Alexey Dobriyan
2008-04-23  0:38     ` KaiGai Kohei
2008-04-23  7:03       ` Alexey Dobriyan
2008-04-23  7:37         ` KaiGai Kohei
2008-05-13 22:12           ` Alexey Dobriyan
2008-05-14  0:34             ` KaiGai Kohei [this message]
2008-04-23  5:37   ` Chris Wright
2008-04-23  7:15     ` KaiGai Kohei
2008-05-14  0:36       ` KaiGai Kohei
2008-05-14  0:52         ` Chris Wright
2008-05-14  5:57           ` KaiGai Kohei
2008-05-15  5:48             ` Andrew Morgan
2008-05-15  7:47               ` KaiGai Kohei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=482A338C.6040907@ak.jp.nec.com \
    --to=kaigai@ak.jp.nec.com \
    --cc=adobriyan@gmail.com \
    --cc=chrisw@sous-sol.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=serue@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox