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 80C5EC4360C for ; Tue, 8 Oct 2019 19:41:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 579B321721 for ; Tue, 8 Oct 2019 19:41:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730145AbfJHTlo convert rfc822-to-8bit (ORCPT ); Tue, 8 Oct 2019 15:41:44 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:60722 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728465AbfJHTlo (ORCPT ); Tue, 8 Oct 2019 15:41:44 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1iHvMa-0006qJ-Up; Tue, 08 Oct 2019 13:41:40 -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 1iHvMa-0001Zj-18; Tue, 08 Oct 2019 13:41:40 -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> <87k19geey0.fsf@x220.int.ebiederm.org> Date: Tue, 08 Oct 2019 14:40:55 -0500 In-Reply-To: (Michael Kerrisk's message of "Tue, 8 Oct 2019 16:27:25 +0200") Message-ID: <87eeznc9fc.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=1iHvMa-0001Zj-18;;;mid=<87eeznc9fc.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/hRZtkqxlOa+U99OxC3bfYn7yjgpKKjqE= 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Michael Kerrisk (man-pages)" 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, 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. Eric