Why does devices cgroup check for CAP_SYS_ADMIN explicitly?
Serge Hallyn
serge.hallyn at canonical.com
Tue Nov 6 18:25:15 UTC 2012
Quoting Tejun Heo (tj at kernel.org):
> Hello, Serge.
>
> On Tue, Nov 06, 2012 at 12:12:14PM -0600, Serge Hallyn wrote:
> > Quoting Tejun Heo (tj at kernel.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
More information about the Containers
mailing list