linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
	linux-man <linux-man@vger.kernel.org>,
	Containers <containers@lists.linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Jordan Ogas <jogas@lanl.gov>,
	werner@almesberger.net, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: pivot_root(".", ".") and the fchdir() dance
Date: Tue, 08 Oct 2019 14:40:55 -0500	[thread overview]
Message-ID: <87eeznc9fc.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <c7041c6a-a4c6-75f2-5380-4fed67cd60b1@gmail.com> (Michael Kerrisk's message of "Tue, 8 Oct 2019 16:27:25 +0200")

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

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

I hate to nitpick, but I am going to say that when I read the text above
the phrase "mount namespace of the process that created the new mount
namespace" feels wrong.

Either you use unshare(2) and the mount namespace of the process that
created the mount namespace changes.

Or you use clone(2) and you could argue it is the new child that created
the mount namespace.

Having a different mount namespace at the end of the creation operation
feels like it makes your phrase confusing about what the starting
mount namespace is.  I hate to use references that are ambiguous when
things are changing.

I agree that the term parent is also wrong.

Eric

  reply	other threads:[~2019-10-08 19:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 13:38 pivot_root(".", ".") and the fchdir() dance Michael Kerrisk (man-pages)
2019-08-05 10:36 ` Aleksa Sarai
2019-08-05 12:29   ` Michael Kerrisk (man-pages)
2019-08-05 13:37     ` Aleksa Sarai
2019-08-06 19:35       ` Michael Kerrisk (man-pages)
2019-08-06  8:12     ` Philipp Wendler
2019-08-06 12:03       ` Michael Kerrisk (man-pages)
2019-09-09 10:40         ` Eric W. Biederman
2019-09-09 14:48           ` Michael Kerrisk (man-pages)
2019-09-09 23:40             ` Eric W. Biederman
2019-09-10 10:27               ` Michael Kerrisk (man-pages)
2019-09-10 11:15                 ` Christian Brauner
2019-09-10 11:21                   ` Michael Kerrisk (man-pages)
2019-09-10 23:06                     ` Eric W. Biederman
2019-09-15  8:12                       ` Michael Kerrisk (man-pages)
2019-09-15 18:17                         ` Eric W. Biederman
2019-09-23 11:10                           ` Michael Kerrisk (man-pages)
2019-09-28 15:05                             ` Michael Kerrisk (man-pages)
2019-09-30 11:42                               ` Eric W. Biederman
2019-10-07 11:02                                 ` Michael Kerrisk (man-pages)
2019-10-07 15:46                                   ` Eric W. Biederman
2019-10-08 14:27                                     ` Michael Kerrisk (man-pages)
2019-10-08 19:40                                       ` Eric W. Biederman [this message]
2019-10-08 21:40                                         ` Michael Kerrisk (man-pages)
2019-10-08 22:16                                           ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eeznc9fc.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=jogas@lanl.gov \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mtk.manpages@gmail.com \
    --cc=viro@ftp.linux.org.uk \
    --cc=werner@almesberger.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).