Messages in this thread | | | Date | Thu, 10 Jul 2008 21:19:43 +0530 | From | Dhaval Giani <> | Subject | Re: [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
| |