Quoting Ryota Ozaki (ozaki.ryota(a)gmail.com):
Hi Serge,
On Fri, May 8, 2009 at 11:48 AM, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
> IIUC, the real problem is that src/cgroup.c assumes that the
> cgroup name should be $CGROUP_MOUNTPOINT/groupname. But of
> course if the ns cgroup is enabled, then the unshare(CLONE_NEWNS)
> to create a new namespace in which to mount the new devpts
> locks the driver under $CGROUP_MOUNTPOINT/<pid_of_driver>/
> or somesuch.
>
> If this fixes the problem I have no objections, but it seems
> more fragile than perhaps trying to teach src/cgroup.c to
> consider it's current cgroup as a starting point.
hmm, I don't know why the assumption is bad and how the approach
you are suggesting helps the ns problem.
To be clear, the asssumption is that the driver starts in the
root cgroup, i.e. it's pid is listed in $CGROUP_MOUNTPOINT/tasks.
And that it can create $CGROUP_MOUNTPOINT/groupname and move
itself into $CGROUP_MOUNTPOINT/groupname/tasks.
So, the assumption is bad because when the driver does a
unshare(CLONE_NEWNS), it gets moved into $CGROUP_MOUNTPOINT/X,
and after that can only move itself into
$CGROUP_MOUNTPOINT/X/groupname.
Even with your patch, it's possible for the lxc driver to have
been started under say $CGROUP_MOUNTPOINT/libvir or
$CGROUP_MOUNTPOINT/<username> through libcgroup/PAM for instance,
in which case your patch would be insufficient.
thanks,
-serge
PS
The point of the ns cgroup is to prevent even privileged tasks in a
resource group from escaping that resource group. FWIW this can
currently also be done using selinux/smack, and eventually should
be accomplished using user namespaces. At that point we should
seriously consider removing the movement restriction.