Quoting Paul Menage (menage@xxxxxxxxxx): > On 9/4/07, Serge E. Hallyn <serue@xxxxxxxxxx> wrote: > > We could of course have the ns_container subsystem do that. The > > ns_container generally stick around until the admin does a manual rm on > > its directory, so this way we could keep the nsproxy around. > > So how about taking sys_hijack() even further and integrate it with > control groups too? So when you do sys_hijack() (or maybe an > alternative name would be sys_fork_in()?) you create a task that > inherits all the control groups of the target task, as well as the > namespaces. > > Paul Sorry don't know why i haven't replied to this. Good point. I see container_fork(p) takes the container from current. I can change that to container_fork(src, dest) in my next posting. Is there any reason why we wouldn't want to do that? For instance a container admin could impose some restrictions which would keep the host admin from doing something through sys_hijack()? (Not sure that's a big worry since the restrictions would apply to the container admin as well) thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
