From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7E98C47404 for ; Mon, 7 Oct 2019 15:47:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AD8B620684 for ; Mon, 7 Oct 2019 15:47:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728950AbfJGPrU convert rfc822-to-8bit (ORCPT ); Mon, 7 Oct 2019 11:47:20 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:56793 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728144AbfJGPrT (ORCPT ); Mon, 7 Oct 2019 11:47:19 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1iHVEC-0001aK-Nl; Mon, 07 Oct 2019 09:47:16 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1iHVEB-00026g-HV; Mon, 07 Oct 2019 09:47:16 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: "Michael Kerrisk \(man-pages\)" Cc: Christian Brauner , linux-man , Containers , lkml , Andy Lutomirski , Jordan Ogas , werner@almesberger.net, Al Viro References: <20190805103630.tu4kytsbi5evfrhi@mikami> <3a96c631-6595-b75e-f6a7-db703bf89bcf@gmail.com> <87r24piwhm.fsf@x220.int.ebiederm.org> <87ftl5donm.fsf@x220.int.ebiederm.org> <20190910111551.scam5payogqqvlri@wittgenstein> <30545c5c-ff4c-8b87-e591-40cc0a631304@gmail.com> <871rwnda47.fsf@x220.int.ebiederm.org> <448138b8-0d0c-5eb3-d5e5-04a26912d3a8@gmail.com> <87ef0hbezt.fsf@x220.int.ebiederm.org> <71cad40b-0f9f-24de-b650-8bc4fce78fa8@gmail.com> <87y2y6j9i1.fsf@x220.int.ebiederm.org> <7e4b23df-ab83-3d5a-3dc5-54025e3682cf@gmail.com> Date: Mon, 07 Oct 2019 10:46:31 -0500 In-Reply-To: <7e4b23df-ab83-3d5a-3dc5-54025e3682cf@gmail.com> (Michael Kerrisk's message of "Mon, 7 Oct 2019 14:02:12 +0300") Message-ID: <87k19geey0.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1iHVEB-00026g-HV;;;mid=<87k19geey0.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX189d0SjMc7rVk2x+/2tni/O8jn4nzqR1ZY= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: pivot_root(".", ".") and the fchdir() dance X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org "Michael Kerrisk (man-pages)" writes: > Hello Eric, > > On 9/30/19 2:42 PM, Eric W. Biederman wrote: >> "Michael Kerrisk (man-pages)" writes: >> >>> Hello Eric, >>> >>> A ping on my question below. Could you take a look please? >>> >>> Thanks, >>> >>> Michael >>> >>>>>>> The concern from our conversation at the container mini-summit was that >>>>>>> there is a pathology if in your initial mount namespace all of the >>>>>>> mounts are marked MS_SHARED like systemd does (and is almost necessary >>>>>>> if you are going to use mount propagation), that if new_root itself >>>>>>> is MS_SHARED then unmounting the old_root could propagate. >>>>>>> >>>>>>> So I believe the desired sequence is: >>>>>>> >>>>>>>>>> chdir(new_root); >>>>>>> +++ mount("", ".", MS_SLAVE | MS_REC, NULL); >>>>>>>>>> pivot_root(".", "."); >>>>>>>>>> umount2(".", MNT_DETACH); >>>>>>> >>>>>>> The change to new new_root could be either MS_SLAVE or MS_PRIVATE. So >>>>>>> long as it is not MS_SHARED the mount won't propagate back to the >>>>>>> parent mount namespace. >>>>>> >>>>>> Thanks. I made that change. >>>>> >>>>> For what it is worth. The sequence above without the change in mount >>>>> attributes will fail if it is necessary to change the mount attributes >>>>> as "." is both put_old as well as new_root. >>>>> >>>>> When I initially suggested the change I saw "." was new_root and forgot >>>>> "." was also put_old. So I thought there was a silent danger without >>>>> that sequence. >>>> >>>> So, now I am a little confused by the comments you added here. Do you >>>> now mean that the >>>> >>>> mount("", ".", MS_SLAVE | MS_REC, NULL); >>>> >>>> call is not actually necessary? >> >> Apologies for being slow getting back to you. > > NP. Thanks for your reply. > >> To my knowledge there are two cases where pivot_root is used. >> - In the initial mount namespace from a ramdisk when mounting root. >> This is the original use case and somewhat historical as rootfs >> (aka an initial ramfs) may not be unmounted. >> >> - When setting up a new mount namespace to jettison all of the mounts >> you don't need. >> >> The sequence: >> >> chdir(new_root); >> pivot_root(".", "."); >> umount2(".", MNT_DETACH); >> >> is perfect for both use cases (as nothing needs to be known about the >> directory layout of the new root filesystem). >> >> In the case when you are setting up a new mount namespace propogating >> changes in the mount layout to another mount namespace is fatal. But >> that is not a concern for using that pivot_root sequence above because >> pivot_root will fail deterministically if >> 'mount("", ".", MS_SLAVE | MS_REC, NULL)' is needed but not specified. >> >> So I would document the above sequence of three system calls in the >> man-page. > > Okay. I've changed the example to be just those three calls. > >> I would document that pivot_root will fail if propagation would occur. > > Yep. That's in the page already. > >> I would document in pivot_root or under unshare(CLONE_NEWNS) that if >> mount propagation is enabled (the default with systemd) that you >> need to call 'mount("", "/", MS_SLAVE | MS_REC, NULL);' or >> 'mount("", "/", MS_PRIVATE | MS_REC, NULL);' after creating a mount >> namespace. Or mounts will propagate backwards, which is usually >> not what people want. > > Thanks. Instead, I have added the following text to > mount_namespaces(7), the page that is referred to by both clone(2) and > unshare(2) in their discussions of CLONE_NEWNS: > > An application that creates a new mount namespace > directly using clone(2) or unshare(2) may desire to pre‐ > vent propagation of mount events to other mount names‐ > paces (as is is done by unshare(1)). This can be done by > changing the propagation type of mount points in the new > namesapace to either MS_SLAVE or MS_PRIVATE. using a > call such as the following: > > mount(NULL, "/", MS_SLAVE | MS_REC, NULL); Yes. >> 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). Eric