Received: by 2002:ac8:760c:0:b0:40f:fb00:664b with SMTP id t12csp915376qtq; Thu, 14 Sep 2023 22:14:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH52Iftfw2fkXyA+c6VQoiz7TLE3CYlX3BE3HDygiDH+m1OCWlCLhTA8cPPFbhPOPNLqrIV X-Received: by 2002:a05:6602:2d8b:b0:792:5f79:ef9b with SMTP id k11-20020a0566022d8b00b007925f79ef9bmr1023777iow.1.1694754892896; Thu, 14 Sep 2023 22:14:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694754892; cv=none; d=google.com; s=arc-20160816; b=aCLjvKypjUmZunbi2bStv9MUHVKBXQ7+dTmJr3HFmnSjmk/v3A14fqa+TF959ML+hw XKcI7VCkpW2vNtcSXxI25z0nhWT6XMC1Yrne2EyHe7P2qs5kamRutQ9//sGKs5D1t+ss GarG7/SVnt3V63KQ5IYAzlw/sikO+x6YW+0UPkFngV4mBQ2wMm2Yg+k3CR3NiYs47pS+ XgFeWYYzgyZsCNaX/Iya1+9v3w076UN+bbXRHD7LpMueWOrdcNSt6Xj8CJ88V06+Z5bW uGLhbB55BAYKacezXwHgwrXhEBhhkF+AmaG05a3LfKp7xgu48fEor+dwDFDWqLy5x+uQ P68A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:feedback-id:dkim-signature:dkim-signature; bh=EMHXuxFrQtckqm0xBirePySXvbt3CcrfaVOhphckfLs=; fh=1FZdedWpEWYOo4AU4NdX6jv2zeCVd2TbnB+sjmQW/ig=; b=08xnDzx+nyUhC4XPycyn0uelZ+pB3vL4zQVGxcM8EKTsub0JtWOWXQhmgsNzslW6SZ 1FtWG5SvUuPkgqHezUjo0wv0WYb9BQTTkEeGVapOTOPSM6ZUCuKQop88okCmdghVDARU BPVQLJ3Y0cRWP+GvQ2hvTS4dnhE4kX1lm03gQ3EnFqO+4CHqt0BYR2JmcqyisFHvsBOS C4hxdfyLuss9SQTAZi7FXl+n5ba00Gkb//4iHfTZa/ljBx5xTwzEHf4ztrJXBCINn/C2 MlKZVqtcy4+QESH1U0mvscWbJT0/TeVw3+oqGUbw9Gy6jlR8tYe8iABBolI6y17nSSFk q8SQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@themaw.net header.s=fm1 header.b=HSsubA7d; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=Nt7Fvwzy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id h192-20020a636cc9000000b0056ae965c538si2627382pgc.55.2023.09.14.22.14.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 22:14:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@themaw.net header.s=fm1 header.b=HSsubA7d; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=Nt7Fvwzy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id C2AC981D475F; Thu, 14 Sep 2023 18:00:28 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231199AbjIOBA3 (ORCPT + 99 others); Thu, 14 Sep 2023 21:00:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230399AbjIOBA2 (ORCPT ); Thu, 14 Sep 2023 21:00:28 -0400 Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63BE91FE8; Thu, 14 Sep 2023 18:00:24 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 7E9C83200981; Thu, 14 Sep 2023 21:00:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 14 Sep 2023 21:00:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1694739622; x=1694826022; bh=EMHXuxFrQtckqm0xBirePySXvbt3CcrfaVO hphckfLs=; b=HSsubA7dfjwk6/cnRxTOQ0uirFf9Gu9PicIpc0IRzOcjsTAgrM5 f9LKB8B2XA1qgUXBC19ILZ+KPUBEHWMF+tO5JQpfZsgHhGAp2XIZ5BR1Z3Ji+B9+ pYVFeUqTas32nfcvStjyb0WJTZzIEHPVKQdQK+KWFFj9ocZ6+Kv3vzPk+hieoybW WyKGz2IehR2fd7BJAfrKPOCnKHTEtzbEz1/Vao/2zVNjCIDiMeF/NgLhEbDky/nq /o1scyxxoMCkQv1FjDL7dG7PvVMjomd1rlcQuYymUykPaywU0BLeSMkHSEIiWHDz yepwHMQroaqQJDLn/jUtQHWYvYKbxYh+EEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1694739622; x=1694826022; bh=EMHXuxFrQtckqm0xBirePySXvbt3CcrfaVO hphckfLs=; b=Nt7Fvwzydx2kf2ZlM99uXFbynkHXouVezinuEF4/PTj/k76DHsC P5rwjgrGV12XIFgbv4fzBgw545a0QLrcezFuwGFQ6A+966qMZv/WAbUns471wNec 99StB9hlwq8VNbD71QLnp6x/MPfS5qyDhxPJp5DPHFYB+a7eLSX8baaODA5rwBKF xvp40kK+h34T6obof8MoB/PG8j7Y4l9YKf6IK4FRbI8yV7PQSwWqyg2iRfNKHOSu /KeWZEMPv8ZPeCBeQxr41vbfg3UBUDKS05xkev9KUV4WHgZkOsFFvBNTziNzRTLn sMQYvdmLg4RmlOXjZ4L8ITEWCEVMoQjpdLg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudejuddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefkrghn ucfmvghnthcuoehrrghvvghnsehthhgvmhgrfidrnhgvtheqnecuggftrfgrthhtvghrnh epgedvteevvdefiedvueeujeegtedvheelhfehtefhkefgjeeuffeguefgkeduhfejnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhgrvhgvnh esthhhvghmrgifrdhnvght X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Sep 2023 21:00:16 -0400 (EDT) Message-ID: Date: Fri, 15 Sep 2023 09:00:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [RFC PATCH 3/3] add listmnt(2) syscall To: Amir Goldstein , Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org, linux-security-module@vger.kernel.org, Karel Zak , David Howells , Linus Torvalds , Al Viro , Christian Brauner References: <20230913152238.905247-1-mszeredi@redhat.com> <20230913152238.905247-4-mszeredi@redhat.com> Content-Language: en-US From: Ian Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 14 Sep 2023 18:00:28 -0700 (PDT) On 14/9/23 14:00, Amir Goldstein wrote: > On Wed, Sep 13, 2023 at 6:22 PM Miklos Szeredi wrote: >> Add way to query the children of a particular mount. This is a more >> flexible way to iterate the mount tree than having to parse the complete >> /proc/self/mountinfo. >> >> Lookup the mount by the old (32bit) or new (64bit) mount ID. If a mount >> needs to be queried based on path, then statx(2) can be used to first query >> the mount ID belonging to the path. >> >> Return an array of new (64bit) mount ID's. Without privileges only mounts >> are listed which are reachable from the task's root. >> >> Signed-off-by: Miklos Szeredi >> --- >> arch/x86/entry/syscalls/syscall_64.tbl | 1 + >> fs/namespace.c | 51 ++++++++++++++++++++++++++ >> include/linux/syscalls.h | 2 + >> include/uapi/asm-generic/unistd.h | 5 ++- >> 4 files changed, 58 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl >> index 6d807c30cd16..0d9a47b0ce9b 100644 >> --- a/arch/x86/entry/syscalls/syscall_64.tbl >> +++ b/arch/x86/entry/syscalls/syscall_64.tbl >> @@ -376,6 +376,7 @@ >> 452 common fchmodat2 sys_fchmodat2 >> 453 64 map_shadow_stack sys_map_shadow_stack >> 454 common statmnt sys_statmnt >> +455 common listmnt sys_listmnt >> >> # >> # Due to a historical design error, certain syscalls are numbered differently >> diff --git a/fs/namespace.c b/fs/namespace.c >> index 088a52043bba..5362b1ffb26f 100644 >> --- a/fs/namespace.c >> +++ b/fs/namespace.c >> @@ -4988,6 +4988,57 @@ SYSCALL_DEFINE5(statmnt, u64, mnt_id, >> return err; >> } >> >> +static long do_listmnt(struct vfsmount *mnt, u64 __user *buf, size_t bufsize, >> + const struct path *root) >> +{ >> + struct mount *r, *m = real_mount(mnt); >> + struct path rootmnt = { .mnt = root->mnt, .dentry = root->mnt->mnt_root }; >> + long ctr = 0; >> + >> + if (!capable(CAP_SYS_ADMIN) && >> + !is_path_reachable(m, mnt->mnt_root, &rootmnt)) >> + return -EPERM; >> + >> + list_for_each_entry(r, &m->mnt_mounts, mnt_child) { >> + if (!capable(CAP_SYS_ADMIN) && >> + !is_path_reachable(r, r->mnt.mnt_root, root)) >> + continue; >> + >> + if (ctr >= bufsize) >> + return -EOVERFLOW; >> + if (put_user(r->mnt_id_unique, buf + ctr)) >> + return -EFAULT; >> + ctr++; >> + if (ctr < 0) >> + return -ERANGE; > I think it'd be good for userspace to be able to query required > bufsize with NULL buf, listattr style, rather than having to > guess and re-guess on EOVERFLOW. Agreed, I also think that would be useful. Ian