Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp1417682ima; Sun, 21 Oct 2018 11:15:35 -0700 (PDT) X-Google-Smtp-Source: ACcGV61zgDITnbQ+pwx0WKtTTOn6/3mZo9lT/RdDpLQu+xO1AkILDET2SirPGgkjpHq56Gi63hyc X-Received: by 2002:a63:c40c:: with SMTP id h12-v6mr28157927pgd.298.1540145735756; Sun, 21 Oct 2018 11:15:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540145735; cv=none; d=google.com; s=arc-20160816; b=ns5TT+TeB5lx11lGVSVMisDaesHPQlksVpeQEtcS69CODcPm47AEhAiaF0lupBOQcg GIsX0ClmPr/49e3YT97AOIrf+oqLMyImAofri8XLFtNfkbDiLtFxclJtJe9KCJKPHXOC dMhic4sNmzdH13t1kGgyX6LXVjCW3LPLajdKhIVi7YVKpUTTWexkSsJP7Ku4BXuBL0B0 j91kx0JGnA7/Kp46hBKjDOqalWBwDsj8z/2I2uwQA7eLxFZCIieuTv4Qdkcns6nbJjjf eOEXJGIxcB5RWqDTUSCcFlHUev1cui5+8ZrzO9TsZqdjvhngoT3o+Ywuo5USThkGFuC6 5DPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from; bh=srt133DXbnLuqJcZ6BNh9vU32ZYjv0yaXjlWPafPZTU=; b=Y2MWdjOXdtawefIaxYs5iZYE0Kqn5swqBhnTZSQDnRHWfHxKYHF/hZp18KlSnDrLXs +iJGUBs1uYh0mruWSZo4r80mCRPX2kEXKqDI5cWhkBRRWM5YO0wKjG+dlO0NJku21YtR vFYLCQEYLQ9WTQt1l6SGvNv2ejlF4KSRZNkwQJMDGPI5jsJ/mO5Ab8G7kc3Zswu7RKpY BrcYn9uKRAXQWyqCTT5n2e+MxucD5KUvtihg6usKxJq6BpV2BNsk2DyMIlmtKanEaSIu PflF4zBQhI+iJLnw+y23U/GkMbbOgIC0OiDJTYf2ZtLpOYjK4M/7aCtOIhiW9xIwSDkQ PD5A== 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 p188-v6si34448930pfg.197.2018.10.21.11.15.20; Sun, 21 Oct 2018 11:15:35 -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 S1728069AbeJVBNB (ORCPT + 99 others); Sun, 21 Oct 2018 21:13:01 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:53442 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727714AbeJVBNB (ORCPT ); Sun, 21 Oct 2018 21:13:01 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gEH3E-0007mK-G8; Sun, 21 Oct 2018 10:58:04 -0600 Received: from 67-3-154-154.omah.qwest.net ([67.3.154.154] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gEH3D-0007yc-OM; Sun, 21 Oct 2018 10:58:04 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: David Howells Cc: viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, mszeredi@redhat.com References: <153754740781.17872.7869536526927736855.stgit@warthog.procyon.org.uk> <153754743491.17872.12115848333103740766.stgit@warthog.procyon.org.uk> Date: Sun, 21 Oct 2018 11:57:43 -0500 In-Reply-To: <153754743491.17872.12115848333103740766.stgit@warthog.procyon.org.uk> (David Howells's message of "Fri, 21 Sep 2018 17:30:34 +0100") Message-ID: <877eib5jaw.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1gEH3D-0007yc-OM;;;mid=<877eib5jaw.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.154.154;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18bVWAcQuXvszOJa770FuI2IuHkInykmwg= X-SA-Exim-Connect-IP: 67.3.154.154 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa04.xmission.com X-Spam-Level: *** X-Spam-Status: No, score=3.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TR_Symld_Words,TVD_RCVD_IP,T_TM2_M_HEADER_IN_MSG, T_TooManySym_01,T_TooManySym_02,T_TooManySym_03,XMNoVowels,XMSubLong autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 1.5 TR_Symld_Words too many words that have symbols inside * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;David Howells X-Spam-Relay-Country: X-Spam-Timing: total 346 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 4.2 (1.2%), b_tie_ro: 2.7 (0.8%), parse: 1.73 (0.5%), extract_message_metadata: 21 (5.9%), get_uri_detail_list: 4.3 (1.3%), tests_pri_-1000: 9 (2.7%), tests_pri_-950: 1.91 (0.6%), tests_pri_-900: 1.52 (0.4%), tests_pri_-400: 34 (9.8%), check_bayes: 32 (9.2%), b_tokenize: 13 (3.9%), b_tok_get_all: 9 (2.6%), b_comp_prob: 3.4 (1.0%), b_tok_touch_all: 3.7 (1.1%), b_finish: 0.68 (0.2%), tests_pri_0: 252 (72.9%), check_dkim_signature: 0.84 (0.2%), check_dkim_adsp: 3.8 (1.1%), tests_pri_10: 4.4 (1.3%), tests_pri_500: 11 (3.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12] X-Spam-Flag: No 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 David Howells writes: > From: Al Viro > > Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be > attached by move_mount(2). > > If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is > not detached anymore, it won't be dissolved. move_mount(2) is adjusted > to handle detached source. > > That gives us equivalents of mount --bind and mount --rbind. In light of recent conversations about double umount_tree. Do we want to simply limit ourselves to attaching file->f_path of a FMODE_NEED_UMOUNT file descriptor and clearing FMODE_NEED_UMOUNT when it is attached? Either that or perhaps move the logic into mntput on when to perform the umount_tree? Otherwise I believe we start running into surprising situations: This works: ofd = open_tree(...); dup_fd = openat(ofd, "", O_PATH); mount_move(dup_fd, ...); close(ofd); close(dup_fd); This should fail: ofd = open_tree(...); dup_fd = openat(ofd, "", O_PATH); close(ofd); mount_move(dup_fd, ...); close(dup_fd); Allowing any file descriptor that points to mnt_ns == NULL without MNT_UMOUNT set seems like it is adding flexibility for no reason. > Signed-off-by: Al Viro > Signed-off-by: David Howells > --- > > fs/namespace.c | 26 ++++++++++++++++++++------ > 1 file changed, 20 insertions(+), 6 deletions(-) > > diff --git a/fs/namespace.c b/fs/namespace.c > index dd38141b1723..caf5c55ef555 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -1785,8 +1785,10 @@ void dissolve_on_fput(struct vfsmount *mnt) > { > namespace_lock(); > lock_mount_hash(); > - mntget(mnt); > - umount_tree(real_mount(mnt), UMOUNT_CONNECTED); > + if (!real_mount(mnt)->mnt_ns) { > + mntget(mnt); > + umount_tree(real_mount(mnt), UMOUNT_CONNECTED); > + } ^^^^^^ This change should be unnecessary. > unlock_mount_hash(); > namespace_unlock(); > } > @@ -2393,6 +2395,7 @@ static int do_move_mount(struct path *old_path, struct path *new_path) > struct mount *old; > struct mountpoint *mp; > int err; > + bool attached; > > mp = lock_mount(new_path); > err = PTR_ERR(mp); > @@ -2403,10 +2406,19 @@ static int do_move_mount(struct path *old_path, struct path *new_path) > p = real_mount(new_path->mnt); > > err = -EINVAL; > - if (!check_mnt(p) || !check_mnt(old)) > + /* The mountpoint must be in our namespace. */ > + if (!check_mnt(p)) > + goto out1; > + /* The thing moved should be either ours or completely unattached. */ > + if (old->mnt_ns && !check_mnt(old)) > goto out1; ^^^^^^^^^^^^^^^^^^^^^^^ !old->mnt_ns should only be allowed when it comes from a file descriptor with FMODE_NEED_UMOUNT. > - if (!mnt_has_parent(old)) > + attached = mnt_has_parent(old); > + /* > + * We need to allow open_tree(OPEN_TREE_CLONE) followed by > + * move_mount(), but mustn't allow "/" to be moved. > + */ > + if (old->mnt_ns && !attached) > goto out1; > > if (old->mnt.mnt_flags & MNT_LOCKED) > @@ -2421,7 +2433,7 @@ static int do_move_mount(struct path *old_path, struct path *new_path) > /* > * Don't move a mount residing in a shared parent. > */ > - if (IS_MNT_SHARED(old->mnt_parent)) > + if (attached && IS_MNT_SHARED(old->mnt_parent)) > goto out1; > /* > * Don't move a mount tree containing unbindable mounts to a destination > @@ -2435,7 +2447,7 @@ static int do_move_mount(struct path *old_path, struct path *new_path) > goto out1; > > err = attach_recursive_mnt(old, real_mount(new_path->mnt), mp, > - &parent_path); > + attached ? &parent_path : NULL); > if (err) > goto out1; ^^^^^^^^^^^^^^^^^^^ Somewhere around here we should have code that clears FMODE_NEED_UMOUNT. > @@ -3121,6 +3133,8 @@ SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *, dir_name, > > /* > * Move a mount from one place to another. > + * In combination with open_tree(OPEN_TREE_CLONE [| AT_RECURSIVE]) it can be > + * used to copy a mount subtree. > * > * Note the flags value is a combination of MOVE_MOUNT_* flags. > */