From: Serge Hallyn <serge.hallyn@ubuntu.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>, Tim Hockin <thockin@hockin.org>,
Mike Galbraith <bitbucket@online.de>,
Containers <containers@lists.linux-foundation.org>,
Kay Sievers <kay.sievers@vrfy.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
lpoetter <lpoetter@redhat.com>, Michal Hocko <mhocko@suse.cz>,
"dhaval.giani" <dhaval.giani@gmail.com>,
Tejun Heo <tj@kernel.org>, Cgroups <cgroups@vger.kernel.org>,
workman-devel <workman-devel@redhat.com>
Subject: Re: [Workman-devel] cgroup: status-quo and userland efforts
Date: Fri, 28 Jun 2013 17:40:53 -0500 [thread overview]
Message-ID: <20130628224053.GA9426@tp> (raw)
In-Reply-To: <20130628195917.GG2507@redhat.com>
Quoting Daniel P. Berrange (berrange@redhat.com):
> On Fri, Jun 28, 2013 at 02:01:55PM -0400, Vivek Goyal wrote:
> > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> > > On Thu 27-06-13 22:01:38, Tejun Heo wrote:
> > > > Hello, Mike.
> > > >
> > > > On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote:
> > > > > I always thought that was a very cool feature, mkdir+echo, poof done.
> > > > > Now maybe that interface is suboptimal for serious usage, but it makes
> > > > > the things usable via dirt simple scripts, very flexible, nice.
> > > >
> > > > Oh, that in itself is not bad. I mean, if you're root, it's pretty
> > > > easy to play with and that part is fine. But combined with the
> > > > hierarchical nature of cgroup and file permissions, it encourages
> > > > people to "deligate" subdirectories to less previledged domains,
> > >
> > > OK, this really depends on what you expose to non-root users. I have
> > > seen use cases where admin prepares top-level which is root-only but
> > > it allows creating sub-groups which are under _full_ control of the
> > > subdomain. This worked nicely for memcg for example because hard limit,
> > > oom handling and other knobs are hierarchical so the subdomain cannot
> > > overwrite what admin has said.
> > >
> > > > which
> > > > in turn leads to normal binaries to manipulate them directly, which is
> > > > where the horror begins. We end up exposing control knobs which are
> > > > tightly coupled to kernel implementation details right into lay
> > > > binaries and scripts directly used by end users.
> > > >
> > > > I think this is the first time this happened, which is probably why
> > > > nobody really noticed the mess earlier.
> > > >
> > > > Anyways, if you're root, you can keep doing whatever you want.
> > >
> > > OK, so libcgroup's rules daemon will still work and place my tasks in
> > > appropriate cgroups?
> >
> > Do you use that daemon in practice? For user session logins, I think
> > systemd has plans to put user sessions in a cgroup (kind of making
> > pam_cgroup redundant).
> >
> > Other functionality rulesengined was providing moving tasks automatically
> > in a cgroup based on executable name. I think that was racy and not
> > many people had liked it.
>
> Regardless of the changes being proposed, IMHO, the cgrulesd should
> never be used. It is just outright dangerous for a daemon to be
> arbitrarily re-arranging what cgroups a process is placed in without
> the applications being aware of it. It can only be safely used in a
> scenario where cgroups are exclusively used by the administrator,
> and never used by applications for their own needs.
Even then it's not safe, since if the program quickly forks or clones a
few times, you can end up with some of the tasks being reclassified
and some not.
> > IIUC, systemd can't disable access to cgroupfs from other utilities.
>
> The kernel can exposed a knob that would allow systemd to lock that
> down
Gah - why would you give him that idea? :)
But yes, I'd sort of assume that was coming, eventually.
-serge
next prev parent reply other threads:[~2013-06-28 22:41 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-06 1:21 cgroup: status-quo and userland efforts Tejun Heo
2013-04-08 13:46 ` Glauber Costa
2013-04-08 18:00 ` [Workman-devel] " Vivek Goyal
2013-04-08 18:26 ` Tejun Heo
2013-04-08 23:32 ` Lennart Poettering
2013-04-09 7:37 ` Glauber Costa
2013-04-09 19:11 ` Tejun Heo
2013-04-08 17:59 ` [Workman-devel] " Vivek Goyal
2013-04-08 18:16 ` Tejun Heo
2013-04-08 18:49 ` Tejun Heo
2013-04-08 19:11 ` Vivek Goyal
2013-04-08 19:20 ` Tejun Heo
2013-04-08 19:46 ` Vivek Goyal
2013-04-08 20:02 ` Tejun Heo
2013-04-09 9:50 ` Daniel P. Berrange
2013-04-09 19:38 ` Tejun Heo
2013-04-09 19:46 ` Tejun Heo
2013-04-09 21:04 ` Serge Hallyn
2013-04-09 21:11 ` Tejun Heo
2013-04-16 11:17 ` Li Zefan
2013-04-16 17:10 ` Tejun Heo
2013-04-17 1:29 ` Li Zefan
2013-04-22 21:26 ` Tim Hockin
2013-04-22 21:41 ` Tejun Heo
2013-04-22 22:33 ` Tim Hockin
2013-06-22 23:13 ` Tim Hockin
2013-06-25 0:01 ` Tejun Heo
2013-06-25 4:07 ` Tim Hockin
2013-06-26 21:20 ` Tejun Heo
2013-06-27 0:06 ` Tim Hockin
2013-06-26 23:14 ` David Lang
2013-06-27 1:04 ` Tejun Heo
2013-06-27 3:42 ` Tim Hockin
2013-06-27 17:38 ` Tejun Heo
2013-06-27 20:46 ` Tim Hockin
2013-06-27 21:04 ` Tejun Heo
2013-06-28 18:44 ` Tim Hockin
2013-06-29 16:40 ` Tejun Heo
2015-03-03 21:53 ` Luke Leighton
2015-03-03 21:38 ` Luke Leighton
2015-03-03 21:17 ` Luke Leighton
2015-03-04 5:08 ` David Lang
2015-03-04 11:27 ` Luke Kenneth Casson Leighton
2015-03-04 20:08 ` David Lang
2013-06-27 5:45 ` Mike Galbraith
2013-06-27 13:22 ` Serge Hallyn
2013-06-27 15:29 ` Tim Hockin
2013-06-27 16:18 ` Serge Hallyn
2015-03-03 22:00 ` Luke Leighton
2013-06-27 17:48 ` Tejun Heo
2013-06-27 18:14 ` Serge Hallyn
2013-06-27 18:45 ` Tejun Heo
2013-06-27 18:51 ` Serge Hallyn
2013-06-27 18:52 ` Tejun Heo
2013-06-27 20:52 ` Tim Hockin
2015-03-03 22:08 ` Luke Leighton
2013-06-28 9:09 ` [Workman-devel] " Daniel P. Berrange
2013-06-28 15:53 ` Serge Hallyn
2013-06-28 18:58 ` Tim Hockin
2015-03-03 22:20 ` Luke Leighton
2013-06-27 18:01 ` Tejun Heo
2013-06-28 3:46 ` Mike Galbraith
2013-06-28 4:09 ` Tejun Heo
2013-06-28 4:49 ` Mike Galbraith
2013-06-28 5:01 ` Tejun Heo
2013-06-28 6:00 ` Mike Galbraith
2013-06-28 15:05 ` Michal Hocko
2013-06-28 18:01 ` [Workman-devel] " Vivek Goyal
2013-06-28 19:59 ` Daniel P. Berrange
2013-06-28 22:40 ` Serge Hallyn [this message]
2013-06-28 22:43 ` Tejun Heo
2013-06-30 18:38 ` Michal Hocko
2013-07-15 18:49 ` Vivek Goyal
2013-07-23 14:48 ` Michal Hocko
2013-06-28 18:30 ` Tejun Heo
2013-06-28 18:53 ` Tim Hockin
2013-06-29 1:48 ` Lennart Poettering
2013-06-29 3:05 ` Tim Hockin
2013-06-30 19:39 ` Lennart Poettering
2013-07-01 6:06 ` Tim Hockin
2013-07-02 23:57 ` Thomas Gleixner
2013-07-03 0:44 ` Kay Sievers
2013-07-03 7:37 ` Borislav Petkov
2013-07-03 9:30 ` Thomas Gleixner
2013-07-09 23:12 ` Jiri Kosina
2013-07-03 17:11 ` James Bottomley
2013-06-28 19:18 ` Andy Lutomirski
2013-06-28 19:36 ` Serge Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130628224053.GA9426@tp \
--to=serge.hallyn@ubuntu.com \
--cc=berrange@redhat.com \
--cc=bitbucket@online.de \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=dhaval.giani@gmail.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpoetter@redhat.com \
--cc=mhocko@suse.cz \
--cc=thockin@hockin.org \
--cc=tj@kernel.org \
--cc=vgoyal@redhat.com \
--cc=workman-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).