Re: Why does devices cgroup check for CAP_SYS_ADMIN explicitly?

[Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

Quoting Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org):
> Hello, Serge.
> 
> On Tue, Nov 06, 2012 at 12:12:14PM -0600, Serge Hallyn wrote:
> > Quoting Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org):
> > > On Tue, Nov 06, 2012 at 11:31:04AM -0600, Serge Hallyn wrote:
> > > > We can't generally require a capability to move tasks between cgroups,
> > > > as that will break currently intended uses.  I can create two cgroups,
> > > > chown them to serge, and let serge move between them.
> > > 
> > > Sure, then just live with the cgroupfs based permission check.  What
> > > next?  Should we add CAP_SYS_RESOURCE check to all resource related
> > 
> > That would be the next step, yes.
> 
> Hmmm... I don't know.  What does that buy us?  Fine grained CAP_* is
> to be able to give away privliedges in smaller pieces, right?  If
> we're gonna be requiring root to modify cgroup, what difference does
> it make to have finer grained CAPs specified?
> 
> > > controllers?  Moreover, We're headed to unified hierarchy, so in the
> > > end that means only the user with almost all CAP_* can manipulate
> > > cgroups at all making the whole thing meaningless.
> > 
> > Why meaningless?  Many caps needed to "do everything", but moving
> > a task into the freezer and freezing it, or reducing its allowed
> > memory, would only requiring uid equiv or some limited bit of
> > privilege.
> 
> All controllers will be co-mounted and you'll need all CAPs needed by

Oh.  I thought each controller could only be mounted once, but not
that all must be co-mounted.

Jinkeys.

> all controllers to move tasks between cgroups and there won't be an
> easy way to tell which CAP is missing.  Doesn't sound too useful to
> me.
> 
> > > I don't think applying fine-grained CAP_* to cgroup controllers makes
> > > sense or would be useful in any real sense.  We can introduce, say,
> > > CAP_CGROUP to control access cgroupfs but I think we already have
> > > enough access control to cgroupfs, don't we?
> > 
> > That's the question :)
> > 
> > I feel like we need a list of the various uses people have in mind,
> > so we can figure out which ones are supportable...  but I know there
> > is the whole long thread I've not had time to keep up with, and
> > many answers are probably there.
> 
> Care to give a pointer?

I mean the recent thread you started on cgroup cleanups :)

-serge