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 17:16:59 -0500 [thread overview]
Message-ID: <878spudgro.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <08d2b28b-21cc-e304-f624-bb5bc4ee98f4@gmail.com> (Michael Kerrisk's message of "Tue, 8 Oct 2019 23:40:25 +0200")
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> On 10/8/19 9:40 PM, Eric W. Biederman wrote:
>> "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,
>
> I love it when you nitpick. Thanks for your attention to the details
> of my wording.
>
>> 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.
>
> I see what you mean. My wording is imprecise.
>
> So, I tweaked text earlier in the page so that it now reads
> as follows:
>
> A new mount namespace is created using either clone(2) or
> unshare(2) with the CLONE_NEWNS flag. When a new mount namespace
> is created, its mount point list is initialized as follows:
>
> * If the namespace is created using clone(2), the mount point
> list of the child's namespace is a copy of the mount point list
> in the parent's namespace.
>
> * If the namespace is created using unshare(2), the mount point
> list of the new namespace is a copy of the mount point list in
> the caller's previous mount namespace.
>
> And then I tweaked the text that we are currently discussing to read:
>
> * Each mount namespace has an owner user namespace. As explained
> above, when a new mount namespace is created, its mount point
> list is initialized as a copy of the mount point list of
> another mount namespace. If the new namespaces and the names‐
> pace from which the mount point list was copied are owned by
> different user namespaces, then the new mount namespace is con‐
> sidered less privileged.
>
> How does this look to you now?
Much better thank you.
Eric
prev parent reply other threads:[~2019-10-08 22:17 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
2019-10-08 21:40 ` Michael Kerrisk (man-pages)
2019-10-08 22:16 ` Eric W. Biederman [this message]
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=878spudgro.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).