I have a process that has called unshare
to create a new network namespace with just itself inside. When it calls execve
to launch bash, the ip command shows that I have just an lo
device. If I also create a user namespace and arrange for my process to be root inside the namespace, I can use the ip
command to bring that device up and it works.
I can also use the ip
command to create a veth
device in this namespace. But it doesn't show up in ip netns list
and the new veth
device doesn't show up in the root level namespace (as I'd expect). How do I connect a veth
device in the root-level namespace to my new veth
device inside my process namespace? The ip
command seems to require that the namespace has a name assigned by the ip
command, and mine doesn't because I didn't use ip netns add
to create it.
Maybe I could do it by writing my own program that used the netlink device and set things up. But I'd really prefer not to. Is there a way to do this through the command line?
There must be a way to do it, because docker containers have their own network namespace as well, and that namespace is also unnamed. Yet there is a veth
device inside it that's connected to a veth
device outside it.
My goal is to dynamically create a process isolation context, ideally without needing to become root outside the container. To this end I'm going to be creating a PID namespace, a UID namespace, a network namespace, an IPC namespace, and mount namespace. I may also create a cgroup namespace, but those are newish and I need to be able to run on currently supported versions of SLES, RHEL, and Ubuntu LTS.
I've been working through this one namespace at a time, and I currently have User, PID and mount namespaces working satisfactorily.
I can mount /proc/pid/ns/net
if I must, but I would prefer to do that from inside the user namespace so (again) I don't have to be root outside the namespace. Mostly, I want everything to disappear as soon as all the processes in the namespace are gone. Having a bunch of state to clean up on the filesystem when I'm done would be less than ideal. Though creating it temporarily when the container is first allocated and then immediately removing it is far better than having to clean it up when the container exits.
No, I can't use docker, lxc, rkt, or any other existing solution such that I'd be relying on anything other than bog-standard system utilities (like ip), system libraries like glibc, and Linux system calls.