Bug 1418962

Summary: Broken net:[...] instead of path for net namespaces in /proc/self/mounts
Product: Red Hat Enterprise Linux 7 Reporter: Richard W.M. Jones <rjones>
Component: kernelAssignee: Aristeu Rozanski <arozansk>
kernel sub component: Namespace QA Contact: Chao Ye <cye>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: arozansk, cavery, cye, ebiederm, jen, jsavanyo, ravindrakumar, vmware-gos-qa
Version: 7.4   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-3.10.0-622.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-02 05:37:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1166465, 1404314    

Description Richard W.M. Jones 2017-02-03 09:49:24 UTC
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.

Comment 2 Ravindra Kumar 2017-02-16 18:42:45 UTC
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!

Comment 3 Aristeu Rozanski 2017-02-16 19:10:42 UTC
Perhaps the upstream commit description? (f48cfddc6729ef133933062320039808bafa6f45)

Comment 4 Richard W.M. Jones 2017-02-16 19:14:00 UTC
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.

Comment 5 Rafael Aquini 2017-03-22 00:07:43 UTC
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing

Comment 7 Rafael Aquini 2017-03-22 16:21:40 UTC
Patch(es) available on kernel-3.10.0-622.el7

Comment 11 errata-xmlrpc 2017-08-02 05:37:33 UTC
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