All of lore.kernel.org
 help / color / mirror / Atom feed
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: akpm@osdl.org, morgan@kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Exporting capability code/name pairs
Date: Fri, 28 Dec 2007 10:47:12 +0900	[thread overview]
Message-ID: <477455A0.7060603@ak.jp.nec.com> (raw)
In-Reply-To: <20071227161435.GB9677@sergelap.austin.ibm.com>

Serge E. Hallyn wrote:
> Quoting KaiGai Kohei (kaigai@ak.jp.nec.com):
>> 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 already built libcap
>> cannot have knowledge about new added capabilities.
>>
>> Dynamic collection of code/name pairs of capabilities will resolve this
>> matter.
>>
>> But it is not perfect one. I have a bit concern about this patch now.
>>
>> 1. I want to generate cap_entries array from linux/capability.h
>>    automatically. Is there any good idea?
>> 2. We have to mount securityfs explicitly, or using /etc/fstab.
>>    It can make a matter when we want to use this features
>>    in very early boot sequence.
>>
>> Any comment please.
> 
> I like the idea, but
   - snip -
>> +/*
>> + * capability code/name pairs are exported under /sys/security/capability/
>> + */
>> +struct cap_entry_data {
>> +	unsigned int code;
>> +	const char *name;
>> +};
>> +
>> +static struct cap_entry_data cap_entries[] = {
>> +	/* max number of supported format */
>> +	{ _LINUX_CAPABILITY_VERSION,	"version" },
>> +	/* max number of capability */
>> +	{ CAP_LAST_CAP,			"index" },
>> +	/* list of capabilities */
>> +	{ CAP_CHOWN,			"cap_chown" },
>> +	{ CAP_DAC_OVERRIDE,		"cap_dac_override" },
   - snip -
>> +	{ CAP_MAC_OVERRIDE,		"cap_mac_override" },
>> +	{ CAP_MAC_ADMIN,		"cap_mac_admin" },
>> +	{ -1,				NULL},
>> +};
> 
> I don't like this duplication with the list in include/linux/capability.h.
> Now when a new cap is added, it needs to be
> 
> 	1. added to capability.h
> 	2. swapped as the new CAP_LAST_CAP in capability.h
> 	3. added to this list...
> 
> Could you integrate the two lists (not sure how offhand), or at least
> put them in the same place?

The following script will generate cap_entries[] array.

cat include/linux/capability.h				\
  | egrep '^#define[ \t]+CAP_[A-Z_]+[ \t]+[0-9]+$'	\
  | awk '{ printf("\t{ %s, \"\" },\n", $2, tolower($2)); }'

It is nice to include the result of this script, like as:

static struct cap_entry_data cap_entries[] = {
	/* max number of supported format */
	{ _LINUX_CAPABILITY_VERSION,	"version" },
	/* max number of capability */
	{ CAP_LAST_CAP,			"index" },
#include "capability_names.h"
	{ -1,				NULL },
};

I guess we can put this script on Makefile like as kernel/timeconst.pl doing.

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

  reply	other threads:[~2007-12-28  1:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-27  3:53 [PATCH] Exporting capability code/name pairs KaiGai Kohei
2007-12-27  7:54 ` James Morris
2007-12-27 16:14 ` Serge E. Hallyn
2007-12-28  1:47   ` KaiGai Kohei [this message]
2007-12-28  6:16     ` KaiGai Kohei
2007-12-28  6:54       ` James Morris
2007-12-28  7:33         ` KaiGai Kohei
2007-12-28  9:12       ` James Morris
2008-01-02  8:04         ` KaiGai Kohei
2008-01-02 10:02           ` James Morris
2008-01-04  2:28             ` KaiGai Kohei
2007-12-28 23:07       ` Randy Dunlap
2007-12-30 16:28       ` Andrew Morgan
2008-01-02  8:08         ` KaiGai Kohei
2008-01-03  1:48           ` Andrew Morgan
2008-01-04  1:57             ` 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=477455A0.7060603@ak.jp.nec.com \
    --to=kaigai@ak.jp.nec.com \
    --cc=akpm@osdl.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.