Re: new cg-manager gui tool for managin cgroups

[Lennart Poettering <mzerqung@0pointer.de>]

On Thu, 21.07.11 10:20, Jason Baron (jbaron@redhat.com) wrote:

> > Quite frankly, I think cgrulesd is a really bad idea, since it applies
> > control group limits after a process is already running. This is
> > necessarily racy (and adds quite a burden too, since you ask for
> > notifications on each exec()). I'd claim that cgrulesd is broken by
> > design and cannot be fixed.
> 
> I'm not going to claim that cgrulesd is perfect, but in the case where
> you have untrusted users, you can start their login session in a
> cgroup, and they can't break out of it. I agree it can be racy in the
> case where you want to then further limit that user at run-time (fork
> vs. re-assignment race). Another point, is that the current situation
> can be no worse then the current unconstrained (no cgroup) case,
> especially when you take into account the fact that system services or
> 'trusted services' are going to be properly assigned. Perhaps, the
> authors of cgrulesd can further comment on this issue... 

placing users in cgroups is note done by cgrulesd afaik. The PAM module
does that. (and systemd can do that for you, too).

> > systemd is and will always have to maintain its own hierarchy
> > independently of everybody else.
> 
> My suggestion here was that systemd starts its own hierarchy in some
> default way, and then once configuration info is available it can move
> processes around as required (in most cases there would probably be no
> movement since we don't expect most users to override the defaults). 
> Doesn't it have to do this now, if the user requests some sort of
> customized cgroup configuration?

I'd expect people to just tell systemd about their preferred grouping
(if the default of sticking each service into a group of its own is not
good enough) using the ControlGroup= setting in unit files. This is
trivial to do, and will put things right from the beginning with no
complex moving around.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel