lkml.org 
[lkml]   [2008]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Libcg-devel] [RFC] How to handle the rules engine for cgroups
On Thu, Jul 10, 2008 at 02:07:11AM -0700, Paul Menage wrote:
> Hi Vivek,
>
> On Tue, Jul 1, 2008 at 12:11 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > - netlink is not a reliable protocol.
> > - Messages can be dropped and one can loose message. That means a
> > newly forked process might never go into right group as meant.
>
> One way that you could avoid the unreliability would be to not use
> netlink, but instead use cgroups itself.
>
> What we're looking for is a way to easily distinguish between
> processes that are in the right cgroups, and processes that might be
> in the wrong cgroups. Additionally, we want the children of such
> processes to inherit the same status until we've dealt with them, and
> not be able to change their status themselves.
>
> That sounds a bit like a cgroup. How about the following?
>
> - create a cgroup subsystem called "setuid".
>
> - have a uid_changed() hook called by sys_setuid() and friends; this
> hook would simply attach current to the root cgroup in the "setuid"
> hierarchy if it wasn't already in that cgroup (which can be determined
> with a couple of dereferences from current and no locking, so not
> slowing down the normal case).
>
> - userspace uses this by:
>
> mount the setuid hierarchy, e.g. at /mnt/setuid
> create a child cgroup /mnt/setuid/processed
> while true:
> wait for /mnt/setuid/tasks to be non-empty
> read a pid from /mnt/setuid/tasks
> move that pid to the appropriate cgroups in memory/cpu/etc
> hierarchies if necessary
> move that pid to /mnt/setuid/processed/tasks
>
> i.e. any pid in the root cgroup of the setuid hierarchy is one that
> needs attention and may need to be moved to different cgroups
>

Where I see complications is handling forks happening in that time. It
will take us a long time to ensure that a fork bomb goes into the
correct cgroup as an example.

Also another issue, where does the pid reside in the memory/cpu hierarchy.
If it is not in the correct cgroup at the time of exec, or soon after
exec, the wrong cgroup is getting charged.

I liked the other idea you posted about in the other mail, having
wrappers around. I believe that can be done at distro level, which
should not really be too tough.

Or maybe we can use something like selinux (ok, this really is a shot in
the dark, i should read up before opening my mouth here.)

Thanks,
--
regards,
Dhaval


\
 
 \ /
  Last update: 2008-07-10 17:55    [W:0.217 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site