From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: mtk.manpages@gmail.com, Philipp Wendler <ml@philippwendler.de>,
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, 10 Sep 2019 12:27:27 +0200 [thread overview]
Message-ID: <b8b9d8bd-e959-633f-b879-4bfe4eb0df23@gmail.com> (raw)
In-Reply-To: <87ftl5donm.fsf@x220.int.ebiederm.org>
Hello Eric,
On 9/10/19 1:40 AM, Eric W. Biederman wrote:
[...]
>>> I have just spotted this conversation and I expect if you are going
>>> to use this example it is probably good to document what is going
>>> on so that people can follow along.
>>
>> (Sounds reasonable.)
>>
>>>>> chdir(rootfs)
>>>>> pivot_root(".", ".")
>>>
>>> At this point the mount stack should be:
>>> old_root
>>> new_root
>>> rootfs
>>
>> In this context, what is 'rootfs'? The initramfs? At least, when I
>> examine /proc/PID/mountinfo. When I look at the / mount point in
>> /proc/PID/mountinfo, I see just
>>
>> old_root
>> new_root
>>
>> But nothing below 'new_root'. So, I'm a little puzzled.
>
> I think that is because Al changed /proc/mounts to not display mounts
> that are outside of your current root. But yes there is typically
> the initramfs of file system type rootfs on their. Even when it isn't
> used you have one. Just to keep everything simple I presume.
>
> I haven't double checked lately to be certain it is there but I expect
> it is.
>
>> By the way, why is 'old_root' stacked above 'new_root', do you know? I
>> mean, in this scenario it turns out to be useful, but it's kind of the
>> opposite from what I would have expected. (And if this was a
>> deliverate design decision in pivot_root(), it was never made
>> explicit.)
>
> Oh. It is absolutely explicit and part of the design and it has nothing
> to do with this case.
>
> The pivot_root system calls takes two parameters: new_root and put_old.
>
> In this case the old root is put on put_old (which is the new_root).
> And new_root is made the current root.
>
> The pivot_root code looks everything up before it moves anything. With
> the result it is totally immaterrial which order the moves actually
> happen in the code. Further it is pretty much necessary to look
> everything up before things are moved because the definition of paths
> change.
>
> So it would actually be difficult to have pivot_root(.,.) to do anything
> except what it does today.
>
>
>>> With "." and "/" pointing to new_root.
>>>
>>>>> umount2(".", MNT_DETACH)
>>>
>>> At this point resolving "." starts with new_root and follows up the
>>> mount stack to old-root.
>>
>> Okay.
>>
>>> Ordinarily if you unmount "/" as is happening above you then need to
>>> call chroot and possibly chdir to ensure neither "/" nor "." point to
>>> somewhere other than the unmounted root filesystem. In this specific
>>> case because "/" and "." resolve to new_root under the filesystem that is
>>> being unmounted that all is well.
>>
>> s/that/then/ ?
Thanks for the further clarifications.
All: I plan to add the following text to the manual page:
new_root and put_old may be the same directory. In particular,
the following sequence allows a pivot-root operation without need‐
ing to create and remove a temporary directory:
chdir(new_root);
pivot_root(".", ".");
umount2(".", MNT_DETACH);
This sequence succeeds because the pivot_root() call stacks the
old root mount point (old_root) on top of the new root mount point
at /. At that point, the calling process's root directory and
current working directory refer to the new root mount point
(new_root). During the subsequent umount() call, resolution of
"." starts with new_root and then moves up the list of mounts
stacked at /, with the result that old_root is unmounted.
Look okay?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2019-09-10 10:27 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) [this message]
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
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=b8b9d8bd-e959-633f-b879-4bfe4eb0df23@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=jogas@lanl.gov \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=ml@philippwendler.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.