Hide Forgot
Description of problem: On RHEL 7: # ip netns add fred # tail -1 /proc/self/mounts proc net:[4026532208] proc rw,nosuid,nodev,noexec,relatime 0 0 # ip netns del fred But on upstream kernels: # ip netns add fred # tail -1 /proc/self/mounts nsfs /run/netns/fred nsfs rw 0 0 # ip netns del fred Notice that on RHEL 7, the second field (mnt_dir) shows a non-path net:[INODE], but on upstream kernels this is resolved to a path. This difference matters for open-vm-tools & container support, see bug 1166465. I believe the fix for this is the following, which is not currently included in the RHEL 7 kernel: commit f48cfddc6729ef133933062320039808bafa6f45 Author: Eric W. Biederman <ebiederm> Date: Fri Nov 8 16:31:29 2013 -0800 vfs: In d_path don't call d_dname on a mount point Aditya Kali (adityakali) wrote: > Commit bf056bfa80596a5d14b26b17276a56a0dcb080e5: > "proc: Fix the namespace inode permission checks." converted > the namespace files into symlinks. The same commit changed > the way namespace bind mounts appear in /proc/mounts: > $ mount --bind /proc/self/ns/ipc /mnt/ipc > Originally: > $ cat /proc/mounts | grep ipc > proc /mnt/ipc proc rw,nosuid,nodev,noexec 0 0 > > After commit bf056bfa80596a5d14b26b17276a56a0dcb080e5: > $ cat /proc/mounts | grep ipc > proc ipc:[4026531839] proc rw,nosuid,nodev,noexec 0 0 > > This breaks userspace which expects the 2nd field in > /proc/mounts to be a valid path. The symlink /proc/<pid>/ns/{ipc,mnt,net,pid,user,uts} point to dentries allocated with d_alloc_pseudo that we can mount, and that have interesting names printed out with d_dname. When these files are bind mounted /proc/mounts is not currently displaying the mount point correctly because d_dname is called instead of just displaying the path where the file is mounted. Solve this by adding an explicit check to distinguish mounted pseudo inodes and unmounted pseudo inodes. Unmounted pseudo inodes always use mount of their filesstem as the mnt_root in their path making these two cases easy to distinguish. CC: stable.org Acked-by: Serge Hallyn <serge.hallyn> Reported-by: Aditya Kali <adityakali> Signed-off-by: "Eric W. Biederman" <ebiederm> Version-Release number of selected component (if applicable): kernel-3.10.0-514.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. See steps in the description above.
Could we refer this bug in our documentation/KB? Or, will there be any public documentation for this issue that we can refer to? Thanks!
Perhaps the upstream commit description? (f48cfddc6729ef133933062320039808bafa6f45)
I'm making the bug public anyway because there is no secret here - the fix has been upstream for years. So either refer to the commit as Aristeu says or to this bug, as you wish.
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing
Patch(es) available on kernel-3.10.0-622.el7
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:1842