netdev - Do not create /var/run/netns mount point when /var/run is already MS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAC1kPDMV_8H8k=fP_Ty5-e-rCompUdFX2dzqszj+CyvVK_VWMg@mail.gmail.com>
Date: Wed, 4 Feb 2026 15:26:47 +0800
From: Chen Linxuan <me@...ck-desk.cn>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: netdev@...r.kernel.org
Subject: Do not create /var/run/netns mount point when /var/run is already MS_SHARED

I have observed a weird redundancy
in the mount table when using `ip netns add` on Ubuntu 24.04.3 LTS.
Specifically, `/proc/self/mountinfo`
show two identical entries for the same network namespace under `/run/netns/`:

ip netns add xxx
cat /proc/self/mountinfo

29 31 0:26 / /run rw,nosuid,nodev,noexec,relatime shared:5 - tmpfs
tmpfs rw,size=744632k,mode=755,inode64
33 29 0:31 / /run/lock rw,nosuid,nodev,noexec,relatime shared:6 -
tmpfs tmpfs rw,size=5120k,inode64
79 29 0:40 / /run/qemu rw,nosuid,nodev,relatime shared:116 - tmpfs
tmpfs rw,mode=755,inode64
92 29 0:26 /snapd/ns /run/snapd/ns rw,nosuid,nodev,noexec,relatime -
tmpfs tmpfs rw,size=744632k,mode=755,inode64
1808 92 0:4 mnt:[4026532752] /run/snapd/ns/cups.mnt rw - nsfs nsfs rw
1991 92 0:4 mnt:[4026532753] /run/snapd/ns/canonical-livepatch.mnt rw
- nsfs nsfs rw
2608 92 0:4 mnt:[4026532940]
/run/snapd/ns/snapd-desktop-integration.mnt rw - nsfs nsfs rw
2677 29 0:87 / /run/user/1000 rw,nosuid,nodev,relatime shared:1632 -
tmpfs tmpfs rw,size=744628k,nr_inodes=186157,mode=700,uid=1000,gid=1000,inode64
3091 2677 0:90 / /run/user/1000/doc rw,nosuid,nodev,relatime
shared:1727 - fuse.portal portal rw,user_id=1000,group_id=1000
3087 2677 0:88 / /run/user/1000/gvfs rw,nosuid,nodev,relatime
shared:1751 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=1000,group_id=1000
104 29 0:26 /netns /run/netns rw,nosuid,nodev,noexec,relatime shared:5
- tmpfs tmpfs rw,size=744632k,mode=755,inode64
746 104 0:4 net:[4026532740] /run/netns/xxx rw shared:984 - nsfs nsfs rw
854 29 0:4 net:[4026532740] /run/netns/xxx rw shared:984 - nsfs nsfs rw

I did some research myself and I found:

1. In iproute2 commit 58a3e8270fe7 ("ip netns:  Make /var/run/netns a
shared mount"),
   the tool began performing a self-bind mount on `/var/run/netns` and setting
   it to MS_SHARED. This might be necessary in 2013 to ensure netns
   propagation when the parent directory (usually `/run`) was private.

2. In systemd commit b3ac5f8cb987 ("mount-setup: make /run shared by default"),
   systemd changed the default propagation of `/run` to shared for a
similar reason after v188.

I have tested a modified version of iproute2 6.1.0 where I removed the explicit
self-bind mount and MS_SHARED configuration logic from `ip/ipnetns.c`.

I confirmed that:
- Network namespaces are still correctly propagated across mount
  namespaces due to the parent `/run` already being shared.
- The redundant "mirrored" mount entries in `mountinfo` disappear.

Should we consider optimizing `ip netns` to check the propagation state of
`/run/netns` or its parent before forcing a new bind-mount? If the environment
is already MS_SHARED, we could skip these steps to keep the mount table clean.