Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx): > On Mon, Jul 28, 2014 at 9:51 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > > Quoting Aditya Kali (adityakali@xxxxxxxxxx): > >> Thank you for your review. I have tried to respond to both your emails here. > >> > >> On Thu, Jul 24, 2014 at 9:36 AM, Serge Hallyn <serge.hallyn@xxxxxxxxxx> wrote: > >> > Quoting Aditya Kali (adityakali@xxxxxxxxxx): > >> >> Background > >> >> Cgroups and Namespaces are used together to create “virtual” > >> >> containers that isolates the host environment from the processes > >> >> running in container. But since cgroups themselves are not > >> >> “virtualized”, the task is always able to see global cgroups view > >> >> through cgroupfs mount and via /proc/self/cgroup file. > >> >> > >> > Hi, > >> > > >> > A few questions/comments: > >> > > >> > 1. Based on this description, am I to understand that after doing a > >> > cgroupns unshare, 'mount -t cgroup cgroup /mnt' by default will > >> > still mount the global root cgroup? Any plans on "changing" that? > >> > >> This is suggested in the "Possible Extensions of CGROUPNS" section. > >> More details below. > >> > >> > Will attempts to change settings of a cgroup which is not under > >> > our current ns be rejected? (That should be easy to do given your > >> > patch 1/5). Sorry if it's done in the set, I'm jumping around... > >> > > >> > >> Currently, only 'cgroup_attach_task', 'cgroup_mkdir' and > >> 'cgroup_rmdir' of cgroups outside of cgroupns-root are prevented. The > >> read/write of actual cgroup properties are not prevented. Usual > >> permission checks continue to apply for those. I was hoping that > >> should be enough, but see more comments towards the end. > >> > >> > 2. What would be the reprecussions of allowing cgroupns unshare so > >> > long as you have ns_capable(CAP_SYS_ADMIN) to the user_ns which > >> > created your current ns cgroup? It'd be a shame if that wasn't > >> > on the roadmap. > >> > > >> > >> Its certainly on the roadmap, just that some logistics were not clear > >> at this time. As pointed out by Andy Lutomirski on [PATCH 5/5] of this > >> series, if we allow cgroupns creation to ns_capable(CAP_SYS_ADMIN) > >> processes, we may need some kind of explicit permission from the > >> cgroup subsystem to allow this. One approach could be an explicit > > > > So long as you do ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN) I think > > you're fine. > > > > The only real problem I can think of with unsharing a cgroup_ns is that > > you could lock a setuid-root application someplace it wasn't expecting. > > The above check guarantees that you were privileged enough that you'd > > better be trusted in this user namespace. > > > > (Unless there is some possible interaction I'm overlooking) > > I think that, if it's done this way, you'd have to unshare cgroupns > before unsharing userns, since you forfeit that capability when you > unshare your userns. That means that the new cgroupns ends up being > associated w/ the root userns, which may not be what you want. > > You could unshare both namespaces in one syscall and give that some > magic semantics, but that's kind of weird. It would be nice if you > could unshare your userns and temporarily retains caps in the parent, > but there is no such mechanism right now. Hm, good point. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
