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:37:17 +0100
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Miklos Szeredi <mszeredi@...hat.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

Hello Miklos,

On 20 November 2017 at 10:22, Miklos Szeredi <mszeredi@...hat.com> wrote:
> 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! And thanks for the fast review and response.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ