Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp2593309ybh; Mon, 5 Aug 2019 03:37:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxuWXJhVfWLCFrywGp0VXVrA2ZiYNiXa3cpF0kwRNLUssV2DPJq0D8QZvTIB4cQ1dgHU8NG X-Received: by 2002:a17:90a:5884:: with SMTP id j4mr18202412pji.142.1565001422339; Mon, 05 Aug 2019 03:37:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565001422; cv=none; d=google.com; s=arc-20160816; b=e9vGHQbsvB1HZo79kIZfE7Jr7wYYcdIuhITfaw7NeE8RjhtoST7kDTY6Dt8nzRgNl1 vLJafXwL9UkpDM8WejSHV6MRlVZegDgG0AwHhkzQ9GoVuEVL4qkE9WgG8Hz1hcfvuvPx CoKqK54YtvejXLwU61UTywuIuOeyvbjNrYKZ66yGJz/fmjYqOgU/JlxjpPlw4JzBYQwh b4hUMRaEcP+zwue8CUVJIOY3+wBfuSrsCwo/TMezychdBl1sWY6ztOid61HGePjjtnKT 1Hw4I2gK9rsKxtwN7jzqPu2kiEMunUIxSBw9Ht9EzTzucYE1M6mk694kD/MmQBdzWvhz 3wxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Q/7TbD9qMMraUU5elArJKXmy+RB/HOiDWO2t3gZOGmU=; b=E2eBz68Lj4HJ13L2rAP0VS17HXX9XbLya4xOFj+86pkmLlxrW6XJo4c7KVXfisb98E 1oVLneMalJtJ7LQBnH5mObVT4El6x9u/AlDonmYh5NF6mJv2rAhgSY6aWv8NH9s37i5a d++BLSoAkKM+UdvD+Emj5vvhLHJnWLaELR3hAKmTpfdlpOa9UdJIwtZ5DigKY4dH386B I7+cyIKi1ytwjSWATgilw5HErwtDvJr0sxhv/SWzdsfBQuje6bYiiFPCOE5zPkWOR+hJ 102iwEB55i7TRKMNzVuiyoVQE33aJb1CfjC+z8pg9QoI/iyjeH/wBI+QmxVzNmcD5XxD ZgCw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y15si12922808pjp.90.2019.08.05.03.36.46; Mon, 05 Aug 2019 03:37:02 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728113AbfHEKgJ (ORCPT + 99 others); Mon, 5 Aug 2019 06:36:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:41924 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727230AbfHEKgJ (ORCPT ); Mon, 5 Aug 2019 06:36:09 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CF319AB92; Mon, 5 Aug 2019 10:36:07 +0000 (UTC) Date: Mon, 5 Aug 2019 20:36:30 +1000 From: Aleksa Sarai To: "Michael Kerrisk (man-pages)" Cc: "Serge E. Hallyn" , linux-man , Containers , lkml , Andy Lutomirski , Jordan Ogas , Al Viro Subject: Re: pivot_root(".", ".") and the fchdir() dance Message-ID: <20190805103630.tu4kytsbi5evfrhi@mikami> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6qypzrljzt2mkjjn" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --6qypzrljzt2mkjjn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-08-01, Michael Kerrisk (man-pages) wrote: > I'd like to add some documentation about the pivot_root(".", ".") > idea, but I have a doubt/question. In the lxc_pivot_root() code we > have these steps >=20 > oldroot =3D open("/", O_DIRECTORY | O_RDONLY | O_CLOEXEC); > newroot =3D open(rootfs, O_DIRECTORY | O_RDONLY | O_CLOEXEC); >=20 > fchdir(newroot); > pivot_root(".", "."); >=20 > fchdir(oldroot); // **** This one is "required" because (as the pivot_root(2) man page states), it's technically not guaranteed by the kernel that the process's cwd will be the same after pivot_root(2): > pivot_root() may or may not change the current root and the current > working directory of any processes or threads which use the old root > directory. Now, if it turns out that we can rely on the current behaviour (and the man page you're improving is actually inaccurate on this point) then you're right that this fchdir(2) isn't required. > mount("", ".", "", MS_SLAVE | MS_REC, NULL); > umount2(".", MNT_DETACH); > fchdir(newroot); // **** And this one is required because we are in @oldroot at this point, due to the first fchdir(2). If we don't have the first one, then switching =66rom "." to "/" in the mount/umount2 calls should fix the issue. We do something very similar to this in runc as well[1] (though, as the commit message says, I "borrowed" the idea from LXC). [1]: https://github.com/opencontainers/runc/commit/f8e6b5af5e120ab7599885bd= 13a932d970ccc748 --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --6qypzrljzt2mkjjn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXzbGxhtUYBJKdfWmnhiqJn3bjbQFAl1IBqsACgkQnhiqJn3b jbTjfw/+Pnh6zFLbDf4UKFZiPT2tLK91Q5TuWjlmjWxJxZMtGNxvDyQiyYXaNXn7 rskiOzCFTl2i3N5BJZCuT3LPfT9+jdHQ1lYowlGZh0AVSQrWksAUsEEumyMFxqpo /ltTRWeQG51pqiqW+Nutd5VH3qsaHT2WfNYHnGSuzyHn+lykwgLymnE7MzjgGPZV vm9IGDEQmpHMZuc6cAxKzC74Fa98QDmKS0K0R32GaLFc7Y28HNnDq/fnNbzAkVYO OwGDY1p97vVk6Zc0MOQuyjAYng+lnaD+wp1uEYai8hpPud5AZ6WBxFke5l83TKjk lJgYx+CT+/inlUcRZ7X8/8MofET/P8K65fteEL+SvoSpBakVmztMVKIvasll+eja 81rffEeIy+3X8pRhSSN8R3yFLk29uw+oQxj5FJlr6IGX0uiRnk1m93KuphlsBg4w jedZ9O+LE2DbjHT43Xz7u0oeeUYVF+Hs2aZXOXbxRGeJl1HiQYlJqW1mdWGwQKKf 1r3zSxaTfXz8svNsHA0fRlZi7S5psoUMRdNEhsQGW/GKr3KTtojUvEqeGGKhW6H4 KgJR6OHlmfRwwgCtiaLx09736H3/m/zG5gPsGTKZGP51LnQWYjpUaUMm+55tSUg9 waJ52wsLxsmJiJ6zYGHzih7sK6LJZMT0ZvqWUXAO5DPK5P2UPqc= =Ti2z -----END PGP SIGNATURE----- --6qypzrljzt2mkjjn--