Re: [Libcg-devel] [RFC] How to handle the rules engine for cgroups

[Dhaval Giani]

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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/