On Thu, Jul 21, 2011 at 10:20:54AM -0400, Jason Baron wrote: [..] > > Quite frankly, I think cgrulesd is a really bad idea, since it applies > > control group limits after a process is already running. This is > > necessarily racy (and adds quite a burden too, since you ask for > > notifications on each exec()). I'd claim that cgrulesd is broken by > > design and cannot be fixed. > > I'm not going to claim that cgrulesd is perfect, but in the case where > you have untrusted users, you can start their login session in a > cgroup, and they can't break out of it. I agree it can be racy in the > case where you want to then further limit that user at run-time (fork > vs. re-assignment race). Another point, is that the current situation > can be no worse then the current unconstrained (no cgroup) case, > especially when you take into account the fact that system services or > 'trusted services' are going to be properly assigned. Perhaps, the > authors of cgrulesd can further comment on this issue... Agreed that cgrulesd reacts after the event and can be racy. It is a best effort kind of situation. A more fool proof way is to launch the task in right cgroup to begin with and that can be done with various other mechianisms available. - pam plugin to put users in right cgroup upon login - cgexec command line tool to launch tasks in right cgroup - Applications make use of libcgroup API to launch/fork tasks in desired cgroup. If none of the above is being used, then cgrulesengd works in the background as best effort to enforce the rules and can easily be turned off, if need be. Thanks Vivek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
