Why does devices cgroup check for CAP_SYS_ADMIN explicitly?

Tejun Heo tj at kernel.org
Tue Nov 6 18:16:23 UTC 2012


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
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?

Thanks.

-- 
tejun


More information about the Containers mailing list