[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150209234207.GB23215@cloud>
Date: Mon, 9 Feb 2015 15:42:08 -0800
From: josh@...htriplett.org
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Iulia Manda <iulia.manda21@...il.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
Michal Hocko <mhocko@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Serge Hallyn <serge.hallyn@...onical.com>,
Darren Hart <dvhart@...ux.intel.com>,
Tim Bird <tim.bird@...ymobile.com>
Subject: Re: [PATCH v3] kernel: Conditionally support non-root users,
groups and capabilities
On Sun, Feb 08, 2015 at 10:05:25AM +0100, Geert Uytterhoeven wrote:
> Thanks for the update!
>
> Acked-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Thanks, Geert!
On Sun, Feb 08, 2015 at 08:02:17PM -0800, Paul E. McKenney wrote:
> I presume that v4 will have your Signed-off-by. ;-)
>
> Testing on my rcutorture setup uncovered an additional required dependency,
> please see patch at the end of this email. With that fix, either separately
> or merged into your patch:
>
> Tested-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
>
> One question below about moving the definition of capable(). Either way:
Answer below.
> Reviewed-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Thanks, Paul!
Based on this feedback, as well as the feedback from others on prior
versions that has since been addressed, once there's a v4 with the
changes suggested by Paul (and the signoff and acks/reviews added), I'm
going to let this patch start cooking in linux-next (after the currently
active merge window closes, of course). That'll help shake out any
other potential missing dependencies or merge issues, and leave plenty
of time for people to discuss it further before the subsequent merge
window.
> > --- a/kernel/capability.c
> > +++ b/kernel/capability.c
> > @@ -35,6 +35,7 @@ static int __init file_caps_disable(char *str)
> > }
> > __setup("no_file_caps", file_caps_disable);
> >
> > +#ifdef CONFIG_MULTIUSER
> > /*
> > * More recent versions of libcap are available from:
> > *
> > @@ -386,6 +387,24 @@ bool ns_capable(struct user_namespace *ns, int cap)
> > }
> > EXPORT_SYMBOL(ns_capable);
> >
> > +
> > +/**
> > + * capable - Determine if the current task has a superior capability in effect
> > + * @cap: The capability to be tested for
> > + *
> > + * Return true if the current task has the given superior capability currently
> > + * available for use, false if not.
> > + *
> > + * This sets PF_SUPERPRIV on the task if the capability is available on the
> > + * assumption that it's about to be used.
> > + */
> > +bool capable(int cap)
> > +{
> > + return ns_capable(&init_user_ns, cap);
> > +}
> > +EXPORT_SYMBOL(capable);
> > +#endif /* CONFIG_MULTIUSER */
> > +
> > /**
> > * file_ns_capable - Determine if the file's opener had a capability in effect
> > * @file: The file we want to check
> > @@ -412,22 +431,6 @@ bool file_ns_capable(const struct file *file, struct user_namespace *ns,
> > EXPORT_SYMBOL(file_ns_capable);
> >
> > /**
> > - * capable - Determine if the current task has a superior capability in effect
> > - * @cap: The capability to be tested for
> > - *
> > - * Return true if the current task has the given superior capability currently
> > - * available for use, false if not.
> > - *
> > - * This sets PF_SUPERPRIV on the task if the capability is available on the
> > - * assumption that it's about to be used.
> > - */
> > -bool capable(int cap)
> > -{
> > - return ns_capable(&init_user_ns, cap);
> > -}
> > -EXPORT_SYMBOL(capable);
> > -
> > -/**
>
> OK, I'll bite... Why are we moving capable()?
Consolidating from two ifdef blocks to one, based on feedback on the
initial version suggesting simplification of the ifdeffery.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists