new cg-manager gui tool for managin cgroups

Lennart Poettering mzerqung at 0pointer.de
Thu Jul 21 10:55:00 PDT 2011


On Thu, 21.07.11 19:23, Tomas Mraz (tmraz at redhat.com) wrote:

> 
> On Thu, 2011-07-21 at 10:20 -0400, Jason Baron wrote: 
> > Hi,
> > 
> > On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
> > > On Wed, 20.07.11 15:20, Jason Baron (jbaron at redhat.com) wrote:
> > > 
> > > Heya,
> > > 
> > > > The memory and cpu share controllers are currently supported (I simply haven't
> > > > gotten to supporting other controllers yet). One can add/delete cgroups, change
> > > > configuration parameters, and see which processes are currently associated
> > > > with each cgroup. There is also a 'usage' view, which displays graphically the
> > > > real-time usage statistics. The cgroup configuration can then be saved
> > > > into /etc/cgconfig.conf using the 'save' menubar button.
> > > 
> > > How does it write that file? Does the UI run as root? That's not really
> > > desirable. It's not secure and it is cumbersome to mix applications
> > > running as differnt users on the same session and one the same X
> > > screen (since they cannot communicate with dbus, and so on).
> > 
> > Right, as Dan Walsh, mentioned I need to separate this into two parts -
> > the front end UI and a backend communicating via DBUS. This is had been
> > a todo item.
> 
> Note that in case the services that the backend provides for the GUI are
> really powerful there is no real security benefit in separating the GUI
> and backend. 
> 
> I am not sure that a cgroup manager would be such case though.
> 
> For example if the backend service is "interface to enable and configure
> various network based authentication services" as it would be in case of
> authconfig if it was split into GUI and backend, then you can easily
> instruct the backend to authenticate against a network service that will
> give you root user with no password. So we would have to trust the user
> X session that is the authconfig frontend running in anyway.

There's quite a substantial security benefit here. If you use stuff like
PK you can ensure that UIs only ask for and get very specific privileges
when interacting with the mechanism. That means even if you cannot trust
your UI it will be able to do very few bad things only. If you entire UI
runs as roo however, it can do pretty much everything it wants.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the Containers mailing list