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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Nov 2017 10:22:20 +0100
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     Ram Pai <linuxram@...ibm.com>, lkml <linux-kernel@...r.kernel.org>,
        linux-man <linux-man@...r.kernel.org>,
        Alexander Eder <alexander.eder@...man.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: Improving documentation of parent-ID field in /proc/PID/mountinfo

On Mon, Nov 20, 2017 at 10:07 AM, Michael Kerrisk (man-pages)
<mtk.manpages@...il.com> wrote:

> But, the problem is that the existing description is at best misleading:
>
>               (2)  parent  ID: the ID of the parent mount (or of self for
>                    the top of the mount tree).
>
> That implies that we'll find one line in the list where field 1 and
> field 2 are the same. But we don't, because the mountns rootfs entry
> is not shown in mountinfo. On top of that, the reader is left
> confused, because when they look at mountinfo, they see one entry
> where the parent-ID doesn't exist in the list. So, something more than
> the current text is required. After digging around in the kernel
> source and noticing that chroot() will also cause this scenario, and
> taking into account your comments, I revised the text to:
>
>               (2)  parent ID: the ID of the parent mount (or of self  for
>                    the root of this mount namespace's mount tree).
>
>                    If  the  parent mount point lies outside the process's
>                    root directory (see  chroot(2)),  the  ID  shown  here
>                    won't  have  a corresponding record in mountinfo whose
>                    mount ID  (field  1)  matches  this  parent  mount  ID
>                    (because  mount  points that lie outside the process's
>                    root directory are not shown in mountinfo).  As a spe‐
>                    cial  case  of  this  point,  the process's root mount
>                    point may have  a  parent  mount  (for  the  initramfs
>                    filesystem)  that  lies  outside  the  process's  root
>                    directory, and an entry for that mount point will  not
>                    appear in mountinfo.
>
> How does that seem?

Perfect.

Thanks,
Miklos

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ