From: Vivek Goyal <vgoyal@redhat.com>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Paul Menage <menage@google.com>,
righi.andrea@gmail.com,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Kazunaga Ikeno <k-ikeno@ak.jp.nec.com>,
Morton Andrew Morton <akpm@linux-foundation.org>,
Thomas Graf <tgraf@redhat.com>,
Ulrich Drepper <drepper@redhat.com>,
Steve Olivieri <solivier@redhat.com>
Subject: Re: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right cgroup
Date: Tue, 26 Aug 2008 12:08:26 -0400 [thread overview]
Message-ID: <20080826160826.GF30312@redhat.com> (raw)
In-Reply-To: <48B414A0.9000504@linux.vnet.ibm.com>
On Tue, Aug 26, 2008 at 08:05:12PM +0530, Balbir Singh wrote:
> Vivek Goyal wrote:
> > On Mon, Aug 25, 2008 at 05:54:39PM -0700, Paul Menage wrote:
> >> On Tue, Aug 19, 2008 at 5:57 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >>> Same thing will happen if we implement the daemon in user space. A task
> >>> who does seteuid(), can be swept away to a different cgroup based on
> >>> rules specified in /etc/cgrules.conf.
> >> Yes, I'm not so keen on a daemon magically pulling things into a
> >> cgroup based on uid either, for the same reasons.
> >>
> >> But a user-space based solution can be much more flexible (e.g. easier
> >> to configure it to only move tasks from certain source cgroups).
> >>
> >>> What do you mean by risk? This is the policy set up by system admin and
> >>> behaviour would seem consistent as per the policy. If an admin decides
> >>> that tasks of user "apache" should run into /container/cpu/apache cgroup and
> >>> if a "root" tasks does seteuid(apache), then it manes sense to move task
> >>> to /container/cpu/apache.
> >> The kind of unexpected behaviour I was imagining was when some other
> >> daemon (e.g. ftpd?) unexpectedly does a setuid to one of the
> >> magically-controlled users, and results in that daemon being pulled
> >> into the specified cgroup. For something like cpu maybe that's mostly
> >> benign (but what moves it back into its original group after it
> >> switches back to root?)
> >
> > Once ftpd does seteuid() or setreuid() again to switch effective user to
> > "root", it will be moved back to original group (root's group).
> >
> > So basic question is if a program changes its effective user id temporarily
> > to user B than all the resource consumption should take place from the
> > resources of user B or should continue to take place from original cgroup.
> >
> > I would think that we should move the task temporarily to B's cgroup and
> > bring back again upon identity change.
> >
> > At the same time I can also understand that this behavior can probably
> > be considered over-intrusive and some people might want to avoid that.
> >
> > Two things come to my mind.
> >
> > - Users who find it too intrusive, can just shut down the rules based
> > daemon.
> >
>
> Yes, I would say administrators should do that. Classification via setuid(),
> does make a lot of sense, but at the same time it might be too aggressive if an
> application frequently uses setuid()
>
Just minor clarification. Right now all the classification is being done
based on effective uid and effective gid.
[..]
> >>> Exactly what kind of scenario do you have in mind when you want the policy
> >>> to be enforced selectively based on task (tid)?
> >> I was thinking of something like possibly a per-cgroup file (that also
> >> affected child cgroups) rather than a global file. That would also
> >> automatically handle multiple hierarchies.
> >>
> >
> > So there can be two kind of controls.
> >
> > - Create a per cgroup file say "group_pinned", where if 1 is written to
> > "group_pinned" that means daemon will not move tasks from this cgroup upon
> > effective uid/gid changes.
> >
> > - Provide more fine grained control where task movement is not controlled
> > per cgroup, rather per thread id. In that case every cgroup will contain
> > another file "tasks_pinned" which will contain all the tids which cannot
> > be moved from this cgroup by daemon. By default this file will be empty
> > and all the tids are movable.
> >
> > I think initially we can keep things simple and implement "group_pinned"
> > which provides coarse control on the whole group and pins all the tasks
> > in that cgroup.
> >
>
> Hmm... I wonder if we are providing too many knobs. Can't we do something simpler?
I also fear that we are probably providing too many knobs. Until we get
a strong use case, to keep things simple I recommend that for the time
being let us stick to simple user space daemon and user can turn it on
or off based on his needs (whether user wants a cgroup change upon seteuid()
related events). No controls based on group_pinned or tasks_pinned
etc. It is all or none.
Thanks
Vivek
next prev parent reply other threads:[~2008-08-26 16:09 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 19:11 [RFC] How to handle the rules engine for cgroups Vivek Goyal
2008-07-02 9:33 ` Kazunaga Ikeno
2008-07-03 1:19 ` KAMEZAWA Hiroyuki
2008-07-03 15:54 ` Vivek Goyal
2008-07-04 0:34 ` KAMEZAWA Hiroyuki
2008-07-04 3:17 ` Li Zefan
2008-07-08 9:35 ` Balbir Singh
2008-07-08 13:45 ` Vivek Goyal
2008-07-10 9:23 ` Paul Menage
2008-07-10 14:30 ` Vivek Goyal
2008-07-10 15:42 ` Dhaval Giani
2008-07-10 16:51 ` Paul Menage
2008-07-10 14:48 ` Rik van Riel
2008-07-10 15:40 ` Vivek Goyal
2008-07-10 15:56 ` Ulrich Drepper
2008-07-10 17:25 ` Rik van Riel
2008-07-10 17:39 ` Ulrich Drepper
2008-07-10 18:41 ` Vivek Goyal
2008-07-10 22:29 ` Ulrich Drepper
2008-07-11 0:55 ` KAMEZAWA Hiroyuki
2008-07-14 13:57 ` Vivek Goyal
2008-07-14 14:44 ` David Collier-Brown
2008-07-14 15:21 ` Vivek Goyal
2008-07-17 7:05 ` Kazunaga Ikeno
2008-07-17 13:47 ` Vivek Goyal
[not found] ` <20080717170717.GA3718@linux.vnet.ibm.com>
2008-07-18 8:12 ` [Libcg-devel] " Dhaval Giani
2008-07-18 20:12 ` Vivek Goyal
2008-08-17 10:33 ` [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right cgroup Andrea Righi
2008-08-18 12:35 ` Vivek Goyal
2008-08-19 14:35 ` righi.andrea
2008-08-18 21:05 ` Paul Menage
2008-08-19 12:57 ` Vivek Goyal
2008-08-26 0:54 ` Paul Menage
2008-08-26 13:41 ` Vivek Goyal
2008-08-26 14:35 ` Balbir Singh
2008-08-26 15:04 ` David Collier-Brown
2008-08-26 16:00 ` Vivek Goyal
2008-08-26 16:32 ` David Collier-Brown
2008-08-26 16:08 ` Vivek Goyal [this message]
2008-09-04 18:25 ` Paul Menage
2008-08-19 15:12 ` righi.andrea
2008-08-26 0:55 ` Paul Menage
2008-07-14 15:07 ` Re: [RFC] How to handle the rules engine for cgroups kamezawa.hiroyu
2008-07-10 9:07 ` Paul Menage
2008-07-10 14:06 ` Vivek Goyal
2008-07-10 16:41 ` Paul Menage
2008-07-10 17:19 ` Vivek Goyal
2008-07-10 17:27 ` [Libcg-devel] " Dhaval Giani
2008-07-10 14:33 ` Vivek Goyal
2008-07-10 16:46 ` Paul Menage
2008-07-10 17:18 ` [Libcg-devel] " Dhaval Giani
2008-07-10 17:30 ` Paul Menage
2008-07-10 17:44 ` Dhaval Giani
2008-07-10 15:49 ` Dhaval Giani
2008-07-18 9:52 ` KAMEZAWA Hiroyuki
2008-07-18 15:46 ` Paul Menage
2008-07-18 16:39 ` Balbir Singh
2008-07-18 18:55 ` Vivek Goyal
2008-07-18 23:05 ` kamezawa.hiroyu
2008-07-18 23:10 ` kamezawa.hiroyu
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=20080826160826.GF30312@redhat.com \
--to=vgoyal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=drepper@redhat.com \
--cc=k-ikeno@ak.jp.nec.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=righi.andrea@gmail.com \
--cc=solivier@redhat.com \
--cc=tgraf@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).