public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: josh@joshtriplett.org
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Iulia Manda <iulia.manda21@gmail.com>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Michal Hocko <mhocko@suse.cz>
Subject: Re: [PATCH v2] kernel: Conditionally support non-root users, groups and capabilities
Date: Thu, 29 Jan 2015 12:01:45 -0800	[thread overview]
Message-ID: <20150129200145.GA13879@cloud> (raw)
In-Reply-To: <CAMuHMdVeixAcLEb2JZLyPyjEr7Y2nLpmpOLdX90Xjon9jTFquw@mail.gmail.com>

On Thu, Jan 29, 2015 at 07:59:09PM +0100, Geert Uytterhoeven wrote:
> Hi Iulia,
> 
> On Thu, Jan 29, 2015 at 7:43 PM, Iulia Manda <iulia.manda21@gmail.com> wrote:
> > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > index 68b68d7..b2d2116 100644
> > --- a/arch/s390/Kconfig
> > +++ b/arch/s390/Kconfig
> > @@ -324,6 +324,7 @@ config COMPAT
> >         select COMPAT_BINFMT_ELF if BINFMT_ELF
> >         select ARCH_WANT_OLD_COMPAT_IPC
> >         select COMPAT_OLD_SIGACTION
> > +       select NON_ROOT
> 
> > @@ -10,6 +10,7 @@ config LUSTRE_FS
> 
> > +       select NON_ROOT
> 
> > @@ -6,6 +6,7 @@ config NFSD
> 
> > +       select NON_ROOT
> 
> >  config BSD_PROCESS_ACCT
> >         bool "BSD Process Accounting"
> > +       select NON_ROOT
> 
> >  config TASKSTATS
> 
> > +       select NON_ROOT
> 
> Is there a specific reason why you chose to use "select NON_ROOT"
> instead of "depends on NON_ROOT" for all these options?
> As configuring NON_ROOT=n is quite a drastic decision, I don't
> think you should let that be revertable such easily by all those selects.

In the past, there's been quite a bit of negative feedback about
"depends on", because that makes various options invisible and
un-enableable.  (Kconfig can be awkward that way.)  However, I think
it'd be perfectly reasonable to make all of these "depends on NON_ROOT"
instead, if there aren't any objections to doing so.

> > @@ -1140,6 +1142,7 @@ config CHECKPOINT_RESTORE
> >
> >  menuconfig NAMESPACES
> >         bool "Namespaces support" if EXPERT
> > +       depends on NON_ROOT
> 
> > @@ -1352,11 +1355,25 @@ menuconfig EXPERT
> >
> >  config UID16
> >         bool "Enable 16-bit UID system calls" if EXPERT
> > -       depends on HAVE_UID16
> > +       depends on HAVE_UID16 && NON_ROOT
> 
> Ah, finally a few "depends on".
> 
> > +config NON_ROOT
> > +       bool "Multiple users, groups and capabilities support" if EXPERT
> > +       default y
> > +       help
> > +         This option enables support for non-root users, groups and
> > +         capabilities.
> > +
> > +         If you say N here, all processes will run with UID 0, GID 0, and all
> > +         possible capabilities.  Saying N here also compiles out support for
> > +         system calls related to UIDs, GIDs, and capabilities, such as setuid,
> > +         setgid, and capset.
> > +
> > +         If unsure, say Y here.
> 
> I think it would be clearer to use positive instead of negative logic.
> What about calling the option "MULTIUSER" instead of "NON_ROOT"?

Nice name idea; reminiscent of Multics versus UNIX.

The original motivation for CONFIG_NON_ROOT was to ensure that 'y' was
the option that added code to the kernel, so that "allnoconfig" does the
right thing.  As long as the logic stays that way around, changing the
name of the option seems perfectly fine.

(As long as we're bikeshedding: CONFIG_MULTIUSER or CONFIG_MULTI_USER?)

- Josh Triplett

  reply	other threads:[~2015-01-29 20:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29 18:43 [PATCH v2] kernel: Conditionally support non-root users, groups and capabilities Iulia Manda
2015-01-29 18:59 ` Geert Uytterhoeven
2015-01-29 20:01   ` josh [this message]
2015-01-29 20:16     ` Geert Uytterhoeven
2015-01-29 23:44 ` Casey Schaufler
2015-01-30  0:32   ` Paul E. McKenney
2015-01-30  1:25     ` Casey Schaufler
2015-01-30  1:36       ` Paul E. McKenney
2015-01-30  2:25         ` Casey Schaufler
2015-01-30  7:07           ` Paul E. McKenney
2015-01-30 19:13           ` josh
2015-01-30 19:48             ` Casey Schaufler
2015-01-30 20:20               ` Austin S Hemmelgarn
2015-01-30 21:40               ` Josh Triplett
2015-01-30 21:56                 ` Richard Weinberger
2015-01-31 23:30                   ` Paul E. McKenney
2015-01-31 23:33                     ` Richard Weinberger
2015-02-01 19:45                       ` Paul E. McKenney
2015-01-31 17:00               ` Jarkko Sakkinen
2015-01-30  0:43   ` josh
2015-01-30  2:05     ` Casey Schaufler
2015-01-30 21:04       ` Josh Triplett

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=20150129200145.GA13879@cloud \
    --to=josh@joshtriplett.org \
    --cc=akpm@linux-foundation.org \
    --cc=geert@linux-m68k.org \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=iulia.manda21@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=serge.hallyn@canonical.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