Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1418962 - Broken net:[...] instead of path for net namespaces in /proc/self/mounts
Broken net:[...] instead of path for net namespaces in /proc/self/mounts
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Aristeu Rozanski
Chao Ye
:
Depends On:
Blocks: 1404314 1166465
  Show dependency treegraph
 
Reported: 2017-02-03 04:49 EST by Richard W.M. Jones
Modified: 2017-08-02 01:37 EDT (History)
8 users (show)

See Also:
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 01:37:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:1842 normal SHIPPED_LIVE Important: kernel security, bug fix, and enhancement update 2017-08-01 14:22:09 EDT

  None (edit)
Description Richard W.M. Jones 2017-02-03 04:49:24 EST
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@xmission.com>
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@google.com) 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@vger.kernel.org
    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Reported-by: Aditya Kali <adityakali@google.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

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 13:42:45 EST
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 14:10:42 EST
Perhaps the upstream commit description? (f48cfddc6729ef133933062320039808bafa6f45)
Comment 4 Richard W.M. Jones 2017-02-16 14:14:00 EST
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-21 20:07:43 EDT
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing
Comment 7 Rafael Aquini 2017-03-22 12:21:40 EDT
Patch(es) available on kernel-3.10.0-622.el7
Comment 11 errata-xmlrpc 2017-08-02 01:37:33 EDT
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

Note You need to log in before you can comment on or make changes to this bug.