Bug 1418962 - Broken net:[...] instead of path for net namespaces in /proc/self/mounts
Summary: Broken net:[...] instead of path for net namespaces in /proc/self/mounts
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Aristeu Rozanski
QA Contact: Chao Ye
URL:
Whiteboard:
Depends On:
Blocks: 1166465 1404314
TreeView+ depends on / blocked
 
Reported: 2017-02-03 09:49 UTC by Richard W.M. Jones
Modified: 2017-08-02 05:37 UTC (History)
8 users (show)

Fixed In Version: kernel-3.10.0-622.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-02 05:37:33 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:1842 0 normal SHIPPED_LIVE Important: kernel security, bug fix, and enhancement update 2017-08-01 18:22:09 UTC

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@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 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


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