Quoting Tejun Heo (tj@xxxxxxxxxx): > Just one more thing. > > On Tue, Nov 06, 2012 at 09:38:23AM -0800, Tejun Heo wrote: > > Hello, > > > > On Tue, Nov 06, 2012 at 11:31:04AM -0600, Serge Hallyn wrote: > > > We can't generally require a capability to move tasks between cgroups, > > > as that will break currently intended uses. I can create two cgroups, > > > chown them to serge, and let serge move between them. > > > > Sure, then just live with the cgroupfs based permission check. What > > next? Should we add CAP_SYS_RESOURCE check to all resource related > > controllers? Moreover, We're headed to unified hierarchy, so in the > > end that means only the user with almost all CAP_* can manipulate > > cgroups at all making the whole thing meaningless. > > As for using cgroup as !root user, I would advise not doing that. > Again, we're moving toward a unified cgroup hierarchy. You wouldn't > be creating multiple cgroup hierarchies and assigning different user > accesses to them. Also, I would strongly discourage chowning sub > directories in cgroupfs and letting non-priviledged users modify them > directly. So to be clear, if I want a user to be able to confine his own compute-intensive tasks and freeze them, the recommended route will be with privileged (setuid-root) helpers? -serge -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
