All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kohei KaiGai <kaigai@ak.jp.nec.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "Andrew G. Morgan" <morgan@kernel.org>,
	akpm@osdl.org, jmorris@namei.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] exporting capability code/name pairs (try #4)
Date: Wed, 13 Feb 2008 17:01:55 +0900	[thread overview]
Message-ID: <47B2A3F3.8060701@ak.jp.nec.com> (raw)
In-Reply-To: <20080212180859.GA12876@sergelap.austin.ibm.com>

Serge E. Hallyn wrote:
> Quoting Kohei KaiGai (kaigai@ak.jp.nec.com):
>> 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 SECURITY_CAPABILITIES_EXPORT
>> +	bool "Exporting capabilities kernel supported"
>> +	depends on SECURITY_CAPABILITIES && SYSFS
> 
> Oh no, we're being bit by this again...  When SECURITY=n, capabilities
> are compiled in but SECURITY_CAPABILITIES=n.
> 
> Months ago I floated the following patch so we'd have a CONFIG variable
> to let us know whether commoncap is compiled in.  You might want to use
> this and depend on CONFIG_COMMONCAP?  (Though really I personally don't
> think you need your own config variable for this)

I also think its own config variable is not necessary to turn on/off
exporting the list of capabilities in actually.
Do you want this feture to be moved into security/commoncap.c and
enabled unconditionally? I can agree this suggestion.

Is there any complaint for this idea?

Thanks,

> Other than that, this tested fine for me.
> 
> thanks,
> -serge
> 
>>From 54c70ca7671750fe8986451fae91d42107d0ca90 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <serue@us.ibm.com>
> Date: Fri, 28 Sep 2007 10:33:33 -0500
> Subject: [PATCH 1/2] capabilities: define CONFIG_COMMONCAP
> 
> currently the compilation of commoncap.c is determined
> through Makefile logic.  So there is no single CONFIG
> variable which can be relied upon to know whether it
> will be compiled.
> 
> Define CONFIG_COMMONCAP to be true when lsm is not
> compiled in, or when the capability or rootplug modules
> are compiled.  These are the cases when commoncap is
> currently compiled.  Use this variable in security/Makefile
> to determine commoncap.c's compilation.
> 
> Apart from being a logic cleanup, this is needed by the
> upcoming cap_bset patch so that prctl can know whether
> PR_SET_BSET should be allowed.
> 
> Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
> ---
>  security/Kconfig  |    4 ++++
>  security/Makefile |    9 +++------
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/security/Kconfig b/security/Kconfig
> index 8086e61..02b33fa 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -103,6 +103,10 @@ config SECURITY_ROOTPLUG
>  	  
>  	  If you are unsure how to answer this question, answer N.
>  
> +config COMMONCAP
> +	bool
> +	default !SECURITY || SECURITY_CAPABILITIES || SECURITY_ROOTPLUG
> +
>  source security/selinux/Kconfig
>  
>  endmenu
> diff --git a/security/Makefile b/security/Makefile
> index ef87df2..7cccc81 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -5,14 +5,11 @@
>  obj-$(CONFIG_KEYS)			+= keys/
>  subdir-$(CONFIG_SECURITY_SELINUX)	+= selinux
>  
> -# if we don't select a security model, use the default capabilities
> -ifneq ($(CONFIG_SECURITY),y)
> -obj-y		+= commoncap.o
> -endif
> +obj-$(CONFIG_COMMONCAP)			+= commoncap.o
>  
>  # Object file lists
>  obj-$(CONFIG_SECURITY)			+= security.o dummy.o inode.o
>  # Must precede capability.o in order to stack properly.
>  obj-$(CONFIG_SECURITY_SELINUX)		+= selinux/built-in.o
> -obj-$(CONFIG_SECURITY_CAPABILITIES)	+= commoncap.o capability.o
> -obj-$(CONFIG_SECURITY_ROOTPLUG)		+= commoncap.o root_plug.o
> +obj-$(CONFIG_SECURITY_CAPABILITIES)	+= capability.o
> +obj-$(CONFIG_SECURITY_ROOTPLUG)		+= root_plug.o


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

  reply	other threads:[~2008-02-13  8:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-25  5:18 [PATCH 1/3] exporting capability code/name pairs (try 2nd) Kohei KaiGai
2008-01-25  7:32 ` Andrew G. Morgan
2008-01-25 11:41   ` Kohei KaiGai
2008-02-01  5:17     ` [PATCH 1/3] exporting capability code/name pairs (try #3) Kohei KaiGai
2008-02-04 16:21       ` Serge E. Hallyn
2008-02-06  2:27         ` Kohei KaiGai
2008-02-06  5:08           ` Serge E. Hallyn
2008-02-08  9:42             ` [PATCH] exporting capability code/name pairs (try #4) Kohei KaiGai
2008-02-08 16:48               ` Andrew G. Morgan
2008-02-12  0:56                 ` Kohei KaiGai
2008-02-08 19:23               ` Alexey Dobriyan
2008-02-12  1:10                 ` Kohei KaiGai
2008-02-12 21:58                   ` Alexey Dobriyan
2008-02-13  8:14                     ` Kohei KaiGai
2008-02-12 18:08               ` Serge E. Hallyn
2008-02-13  8:01                 ` Kohei KaiGai [this message]
2008-02-15  1:38                   ` [PATCH] exporting capability code/name pairs (try #5) Kohei KaiGai
2008-02-15  1:58                     ` Li Zefan
2008-02-15  2:58                       ` [PATCH] exporting capability code/name pairs (try #5.1) Kohei KaiGai
2008-02-15 18:38                         ` Serge E. Hallyn
2008-02-15 18:50                           ` Greg KH
2008-02-18  7:12                             ` Kohei KaiGai
2008-02-18  7:40                               ` Greg KH
2008-02-18  8:45                                 ` Kohei KaiGai
2008-02-19 16:16                                   ` Greg KH
2008-02-20  4:38                                     ` [PATCH] exporting capability code/name pairs (try #6) Kohei KaiGai
2008-02-20  5:02                                       ` Greg KH
2008-02-20  5:38                                         ` Kohei KaiGai
2008-02-20  5:53                                           ` Greg KH
2008-02-20  6:19                                           ` [PATCH] exporting capability code/name pairs (try #6.1) Kohei KaiGai
2008-02-20  6:16                                       ` Kohei KaiGai
2008-02-20  4:39                                     ` [PATCH] exporting capability code/name pairs (try #6) Kohei KaiGai
2008-02-20  6:16                                       ` [PATCH] exporting capability code/name pairs (try #6.1) Kohei KaiGai
2008-02-18 15:15                                 ` [PATCH] exporting capability code/name pairs (try #5.1) Serge E. Hallyn

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=47B2A3F3.8060701@ak.jp.nec.com \
    --to=kaigai@ak.jp.nec.com \
    --cc=akpm@osdl.org \
    --cc=jmorris@namei.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.