2

I was poking around /proc/*/ns, and noticed that namespace files look unfamiliar:

# example from `man namespaces`
$ ls -l /proc/$$/ns
total 0
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 cgroup -> cgroup:[4026531835]
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 ipc -> ipc:[4026531839]
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 net -> net:[4026531969]
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 pid -> pid:[4026531836]
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 pid_for_children -> pid:[4026531834]
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 user -> user:[4026531837]
lrwxrwxrwx. 1 mtk mtk 0 Apr 28 12:46 uts -> uts:[4026531838]

So the namespace files are symlinks to... what? A 'thing' with this 10 digit identifier? I mean, I know 'everything's a file', but I've never seen a file path like this before, where is it?

And, evil hat on, what happens if I touch "/proc/$$/ns/cgroup:[4026531835]", will cgroup now point to my regular file, or whatever it currently is?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
OJFord
  • 1,838
  • 1
  • 16
  • 26

2 Answers2

2

This is the kernel using an existing abstraction to represent a new type of thing. The files don't really "point" to anything, in the traditional symlink sense. The values are effectively handles to namespaces. The kernel uses the information internally to look up the appropriate namespace in their internal data structures.

You'll see a similar type of thing in /proc/<pid>/fd when a process has, for example, a socket:

lrwx------ 1 user group 64 Jun 28 14:35 3 -> 'socket:[17257]'

The kernel will reject attempts to write to these. For example:

# echo hi > /proc/self/ns/ipc
bash: /proc/self/ns/ipc: Operation not permitted

Also, you cannot create a file named, for example ipc:[4026531839], in that directory -- it's in the proc filesystem, so the files/directories there are just an abstraction over the state of the kernel, and the kernel will not allow you to create new files in that directory.

Andy Dalton
  • 13,654
  • 1
  • 25
  • 45
  • Thanks, regarding writing, perhaps the same is true, but I meant writing to a new file as if the existing were a symlink - 'pid:[...]' et al. – OJFord Jun 28 '19 at 21:15
2

These files are presented as symlinks. They point to a pseudo-file belonging to the pseudo-filesystem nsfs. Not including specialized namespace operations (done with clone(2), setns(2), unshare(2), ioctl_ns(2) etc.), the only allowed operations I know of on those files are to open (and close) them, to have a reference when manipulating namespages, or to mount them, to be sure to keep a reference on the namespace even if no process using it exists anymore, as is doing for example ip netns add mynetnamespace.

The only readily available useful piece of information is its inode, which is displayed by the pseudo-symlink (and can be retrieved in a script with stat -L -c %i). It's globally unique (including among all the different types of namespaces) so without specialized tool, it can be compared with an other similar value: equals means it's the same pseudo-file, thus same namespace.

$ ls -l /proc/$$/ns/net
lrwxrwxrwx. 1 user user 0 Jun 29 17:37 /proc/23615/ns/net -> net:[4026531992]
$ stat -c %F /proc/$$/ns/net
symbolic link
$ stat --file-system -L -c %T /proc/$$/ns/net
nsfs
$ stat -L -c %i /proc/$$/ns/net
4026531992

Also:

$ ip netns show
test
$ grep test /proc/mounts
nsfs /run/netns/test nsfs rw 0 0

Example of shell script usage for the network namespace case in an answer of mine: How do I find all interfaces that have been configured in Linux, including those of containers?

A.B
  • 31,762
  • 2
  • 62
  • 101