Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5996198ybe; Tue, 10 Sep 2019 11:55:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqzSs0O+KVzPdcka8ztMJlpaMJKkF8h+ijXk9idGx3Oa24nfsQ62VN3koqxcb/ncan11Zwia X-Received: by 2002:a50:ed0f:: with SMTP id j15mr24698924eds.127.1568141711285; Tue, 10 Sep 2019 11:55:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568141711; cv=none; d=google.com; s=arc-20160816; b=XWUguMAQsA0MYmbRlJ0hjQ01SsXp39FjdN8DWidi+EvmZ3qQzfoZ7BU2u024+l17ck PEcsOdU8i6fJ3Bl1Y7Fv3G8FIOtjiU5YQPK485AsjGXbBFuPn++o+KQR3SU6eW5SxyIc 8vTzXFn9W1ofRcpmSQ4rb3gb07gN6pE/taYCItS/RjJPqRkB7tRxWPTc1xavx7koPhSa rX76xtmGA4LNmzkeIE4TL1+SQbDBsErXNCbPtEd6WTEawnZ0G3Q/q3wg3qp0g3yUnVoB SJmMbFLMJtK9fCiH7cyDsYJWkrTwIjkhprAkJ4ol5OC4cNPo5UzPapyjWvEcQZXb99I2 /JBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:cc:dkim-signature; bh=M85dYA6fKUdS8cNZUlRB8i8xXiXNdMyPlT7kR2zJfY4=; b=UolQRM0zPZKfZDSXvUwlImrPdlsh7I+uXRfombhdC067TEf5CW5Rcd6fjv4Fdwrn0C B3vJkRvxwYEVO/yEz29qKaimwMIwBZnbUbKfIBRO5ygvTZy7Cw4/KReKYhcWeuuHLJ5H OHrjAeLotXDTJc7TDiAYkbeYX5ccnkIoUAB6+67WiNZHPy+FawE32uNQV0d9fTl12u4J lKl0ebLTtxF9kgnlevRC3awb1GC1m0mvH9DEHUXR5BMwC3ThGxtP3u0KzNq9Z5D6dHi5 0EmZL+UxH+XvOx0zqA6ZFVjllRsa46jbG4IVe3UGTB+pCJY1D4Zy4WjIEmbZVBO+erTc tQgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IIf2Hgcp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i12si5488588edb.133.2019.09.10.11.54.47; Tue, 10 Sep 2019 11:55:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IIf2Hgcp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390710AbfIJK1c (ORCPT + 99 others); Tue, 10 Sep 2019 06:27:32 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:38804 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727351AbfIJK1c (ORCPT ); Tue, 10 Sep 2019 06:27:32 -0400 Received: by mail-wr1-f66.google.com with SMTP id l11so19044491wrx.5; Tue, 10 Sep 2019 03:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=cc:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M85dYA6fKUdS8cNZUlRB8i8xXiXNdMyPlT7kR2zJfY4=; b=IIf2HgcpMQ/6IV9JyPXRsFZFYNsE3UwR1A5lVgWRc8As8QqlFea1rDke0w7srDu7T1 PQ0O+XZHkRlVhBzGCH2MPVR8Oz9khv6NF6fbThWVLhwNgAknw04dlGai9aeREvU7tb+3 XiS7eDg8RSMKAMuY6mEbe2A3n+WlQEM8XrrXXuxnHawwjEE7rEZ8RKSCUOCaO9zk9lmS SRUUUrA7V2RXiOKb3ye5uUTo16TeDQQMwtFYoOW2Yaf+yNId0TMLqP3JwKvHyylD/dGR TT+1ebROQD7+GDEfdF2K5dxW6ozmo09TWdyka0/vwi6xKEJuLRIFKiQm9F87rgKRKKWs ibFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M85dYA6fKUdS8cNZUlRB8i8xXiXNdMyPlT7kR2zJfY4=; b=YaqRfCV1WcFYYwp/VKJx7qazq2sbcVMAXEiLmJgJl+nCo+AMQMhNdwB3Jq5k70PF7D v+BEHJlzOU5CDvBpLUlLhe4HvziZzZyvumDuVQ2oOHjukRcKhmyZkOLOUY+kZFqWVEwL /KpKryhJ7WCcgBq0WhoG5T5vETGK7yWQs6IQ0ZMwTycuGDSEQ7FLE0gnaLY0oICzEFOH 19gWQDkFRoS7iv1RHDbw04eg4AG6GYDqYO3fmF/danNrswQH9YCLU1jH5Sp6SpUYBlbk OvLMp3jd+MEEyG08QBPhYLVORaCTvdEOFE0CZgXKvPHhrAwFDG4T4LknFct74LoKm79i eyuA== X-Gm-Message-State: APjAAAWr7UlU/w7H9epZyY057sGrkiAzg8DRS8N6Ax6ni+sLAmK/dQZC izz7DgQcqWGKHJ9m43DOTKU= X-Received: by 2002:adf:8444:: with SMTP id 62mr18215631wrf.202.1568111248962; Tue, 10 Sep 2019 03:27:28 -0700 (PDT) Received: from [10.0.20.253] ([95.157.63.22]) by smtp.gmail.com with ESMTPSA id y3sm15820210wrl.78.2019.09.10.03.27.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Sep 2019 03:27:28 -0700 (PDT) Cc: mtk.manpages@gmail.com, Philipp Wendler , linux-man , Containers , lkml , Andy Lutomirski , Jordan Ogas , werner@almesberger.net, Al Viro Subject: Re: pivot_root(".", ".") and the fchdir() dance To: "Eric W. Biederman" References: <20190805103630.tu4kytsbi5evfrhi@mikami> <3a96c631-6595-b75e-f6a7-db703bf89bcf@gmail.com> <87r24piwhm.fsf@x220.int.ebiederm.org> <87ftl5donm.fsf@x220.int.ebiederm.org> From: "Michael Kerrisk (man-pages)" Message-ID: Date: Tue, 10 Sep 2019 12:27:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87ftl5donm.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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/