Oren Laadan <orenl@xxxxxxxxxxxxxxx> writes: > Daniel Lezcano wrote: >> >> I agree with all the points you and Pavel you talked about but I don't feel >> comfortable to have the current process to switch the pid namespace because of >> the process tree hierarchy (what will be the parent of the process when you >> enter the pid namespace for example). What is the difference with the >> sys_bindns or the sys_hijack, proposed a couple of years ago ? >> >> I did a suggestion some weeks ago about a new syscall 'cloneat' where the >> child process becomes the child of the targeted process specified in the >> syscall. Maybe it would be interesting to replace the 'setns' by, or add, a >> cloneat' syscall with the file descriptor passed as parameter. The >> copy_process function shall not use the nsproxy of the caller but the one >> provided in the fd argument. >> >> The newly created process becomes the child of the process where we retrieve >> the namespace with nsfd and this one have to 'waitpid' it, (the caller of >> cloneat' can not wait it). It's a bit similar with the CLONE_PARENT flag, >> except the creation order is inverted (the father creates for the child). >> >> So when entering the container, we specify the pid 1 of the container which is >> usually a child reaper. >> >> Does it make sense ? > > For what it's worth, I think that this suggestion (cloneat) is the > so far the cleanest to allow a process to enter an existing namespace. If the goal is to enter a container you are probably right. I don't think I have seen how scary the cloneat code is. At least for the network namespace there is a lot of value in being able to just change that single namespace. Having multiple logical network stacks has it's challenges but has a lot of practical applications. Especially when there is the possibility of private ipv4 addresses overlapping, or you have interfaces where you never want to forward between them but you want forwarding enabled. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
