LWN: Comments on "Namespaces in operation, part 2: the namespaces API"

Namespaces in operation, part 2: the namespaces API

mkerrisk — Thu, 30 Jan 2020 01:09:23 +0000

> I presume the answer is yes, and the new
> /proc/PID just winds up with a completely
> unrelated inode from the old one.

That's correct.

Namespaces in operation, part 2: the namespaces API

apollock — Tue, 03 Mar 2015 06:40:29 +0000

I'm curious. If you bind mount the /proc/PID/ns/uts entry, and then the original process goes away, is that PID available for reuse?

I presume the answer is yes, and the new /proc/PID just winds up with a completely unrelated inode from the old one.

Namespaces in operation, part 2: the namespaces API

mkerrisk — Mon, 02 Mar 2015 12:08:29 +0000

One point to note regarding the unshare.c experiment with mount namespaces (shown toward the end of the article)... These days, some distributions (e.g., Fedora) enable mount event propagation (mount --make-shared) by default, so that an unmount in the second namespace would automatically affect the initial namespace as well. To prevent mount event propagation, we need to make / a private mount in the second namespace. See the following example:

$ echo $$      # Show PID of shell in initial mount NS
989
$ readlink /proc/989/ns/mnt
mnt:[4026531840]
$ cat /proc/989/mounts | awk '/test/ { print $1 , $2 , $3}'
/dev/sda3 /test ext4
$ PS1='$sh2 ' sudo ./unshare -m /bin/bash   # Start a new shell in a new mount NS
sh2$ readlink /proc/$$/ns/mnt       # Verify that shell is in different mount NS
mnt:[4026532640]
sh2$ # Check whether / mount point propagates mount events
sh2$ cat /proc/$$/mountinfo | awk '/\/ \/ / {print $4, $5, $6, $7}'
/ / rw,relatime shared:1
sh2$ sudo mount --make-private /    # Prevent propagation of events for /
sh2$ cat /proc/$$/mountinfo | awk '/\/ \/ / {print $4, $5, $6, $7}'
/ / rw,relatime -
sh2$ sudo umount /test              # Unmount /test in second mount NS
sh2$ Verify that mount has been removed in second mount NS
sh2$ cat /proc/$$/mounts | awk '/test/ { print $1 , $2 , $3}'
sh2$ Verify that mount is still present in initial mount NS
sh2$ cat /proc/989/mounts | awk '/test/ { print $1 , $2 ,$3}'
/dev/sda3 /test ext4

For more info about mount propagation, see the kernel source file Documentation/filesystems/sharedsubtree.txt and the mount(8) man page.

Namespaces in operation, part 2: the namespaces API

mathstuf — Sat, 27 Apr 2013 20:38:31 +0000

Anything that ships with XFS enabled (pretty much any distro) can't support user namespaces yet since XFS won't work with them. You're probably stuck compiling your own for now (which is what I did and then tossed it into a VM).

Namespaces in operation, part 2: the namespaces API

wkevils — Sat, 27 Apr 2013 15:50:36 +0000

Did anybody tried the example with the mount namespaces ?

I tried it both on Fedora 18 and Ubuntu 12.10 and it did not
work.
For Fedora 18, it could be because of the shared flags.
(running cat /proc/$$/mountinfo show shared).

But for ubuntu:
cat /proc/$$/mountinfo |grep shared
gives nothing.

I would appreciate if someone that tested it and it worked
will post which OS and which kernel he uses.

rgs
Kevin Wilson

setns syscall via syscall()

bourbaki — Fri, 18 Jan 2013 09:15:45 +0000

If your libc is too old and and does not have the setns() wrapper for the sys_setns syscall, you can use the syscall() function instead (in <sys/syscall.h>).

On x86_64, the sys_setns syscall number is 308, so in ns_exec.c you can do :

syscall(308,fd,0)

instead of

setns(fd,0)

Namespaces in operation, part 2: the namespaces API

kevinm — Thu, 17 Jan 2013 03:03:55 +0000

So with a VPN (or IPv6 tunnel) endpoint that uses TUN/TAP, you could bring up your VPN and pingflood away to your heart's content.

Namespaces in operation, part 2: the namespaces API

tpo — Fri, 11 Jan 2013 11:19:02 +0000

What a wonderful article.

It clearly and comprehensively explains the basics and the use in practice, is technical and easy to read.

Thanks Michael!
*t

Namespaces in operation, part 2: the namespaces API

hallyn — Wed, 09 Jan 2013 01:24:35 +0000

> eg if you create a new user ns and new netns can you say use ping or other root-requiring network ops?

Yes - but only with nics owned by your new network namespace. Which means nics which you create (which won't be hooked into the parent ns), or nics which a privileged task in the parent netns passed into your ns.

Namespaces in operation, part 2: the namespaces API

rvolgers — Wed, 09 Jan 2013 00:23:46 +0000

Looking at the source a user namespace root user has all capabilities within that namespace, and raw socket access is controlled by a ns_capable(...) check, so it should be possible.

I have not tested this, so take it with a grain of salt.

Namespaces in operation, part 2: the namespaces API

justincormack — Tue, 08 Jan 2013 22:04:17 +0000

I have spent a fair amount of time with these interfaces, except the shiny new user namespace, so I am a bit confused by that. If you change to a new user ns and therefore become "root" what can you do? Is it affected by which other namespaces you are in? eg if you create a new user ns and new netns can you say use ping or other root-requiring network ops? I guess I should install a new kernel and experiment...