lkml.org 
[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right cgroup
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()

> - Or, we can implement selective movement of tasks by daemon as suggested by
> you. This will make system more complex but provides more flexibility
> in the sense users can keep daemon running at the same time control
> movement of certain tasks.
>

Applications that really care about moving should use cgroup_attach_task* and
move back otherwise with cgrules parsing turned off.

I see control as a two level hierarchy, automatic and controlled, how do we make
sure that they don't conflict is something I have not thought about yet.

>> but for other subsystems it could be more
>> painful (memory, device access, etc).
>>
>
>
>>> 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?

--
Balbir


\
 
 \ /
  Last update: 2008-08-26 16:37    [W:0.134 / U:1.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site