linux-kernel - Re: pivot_root(".", ".") and the fchdir() dance

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]

Message-ID: <c7041c6a-a4c6-75f2-5380-4fed67cd60b1@gmail.com>
Date:   Tue, 8 Oct 2019 16:27:25 +0200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     mtk.manpages@...il.com,
        Christian Brauner <christian.brauner@...ntu.com>,
        linux-man <linux-man@...r.kernel.org>,
        Containers <containers@...ts.linux-foundation.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Jordan Ogas <jogas@...l.gov>, werner@...esberger.net,
        Al Viro <viro@....linux.org.uk>
Subject: Re: pivot_root(".", ".") and the fchdir() dance

Hello Eric,

>>> Creating of a mount namespace in a user namespace automatically does
>>> 'mount("", "/", MS_SLAVE | MS_REC, NULL);' if the starting mount
>>> namespace was not created in that user namespace.  AKA creating
>>> a mount namespace in a user namespace does the unshare for you.
>>
>> Oh -- I had forgotten that detail. But it is documented
>> (by you, I think) in mount_namespaces(7):
>>
>>        *  A  mount  namespace  has  an  owner user namespace.  A
>>           mount namespace whose owner user namespace is  differ‐
>>           ent  from the owner user namespace of its parent mount
>>           namespace is considered a less privileged mount names‐
>>           pace.
>>
>>        *  When  creating  a  less  privileged  mount  namespace,
>>           shared mounts are reduced to  slave  mounts.   (Shared
>>           and  slave  mounts are discussed below.)  This ensures
>>           that  mappings  performed  in  less  privileged  mount
>>           namespaces will not propagate to more privileged mount
>>           namespaces.
>>
>> There's one point that description that troubles me. There is a
>> reference to "parent mount namespace", but as I understand things
>> there is no parental relationship among mount namespaces instances
>> (or am I wrong?). Should that wording not be rather something
>> like "the mount namespace of the process that created this mount
>> namespace"?
> 
> How about "the mount namespace this mount namespace started as a copy of"
> 
> You are absolutely correct there is no relationship between mount
> namespaces.  There is just the propagation tree between mounts.  (Which
> acts similarly to a parent/child relationship but is not at all the same
> thing).

Thanks. I made the text as follows:

       *  Each  mount  namespace  has  an owner user namespace.  As noted
          above, when a new mount namespace is  created,  it  inherits  a
          copy  of  the  mount  points  from  the  mount namespace of the
          process that created the new mount namespace.  If the two mount
          namespaces are owned by different user namespaces, then the new
          mount namespace is considered less privileged.

Cheers,

Michael


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