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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DAA4E7D275 for ; Tue, 26 Sep 2023 10:06:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234317AbjIZKGQ (ORCPT ); Tue, 26 Sep 2023 06:06:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232671AbjIZKGO (ORCPT ); Tue, 26 Sep 2023 06:06:14 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C39397; Tue, 26 Sep 2023 03:06:08 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22E6EC433C7; Tue, 26 Sep 2023 10:06:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695722768; bh=5onSzf5BNFbFhVXiA+U4L0mSIUR02CQroDNZdJ/Wi8s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mrlvP8M/WGIMxDQUlrAlDtJCIhJZnHOgxzaN4l3cUscNnqxCn8ER5BobU0+J74MCE QkGCBpL/mpoZzwdWQAWchoUjjSzZbJGiXMPs5wnwY1O5Ke+c7JAnCKkCIY4J3krVq1 3I5Ucfi2Q/lddDf4MoiCUadOrNh7FTCHxhTDNefq0c9Uro5lQ9CUy99DiEm0HJLVH+ L8Yj0OX0qmlABgA5Ja/dlIcLitbUSFNVKnGgd0g0QBM3b6m0U2Tsb38gBBySZ+yMmD INRhtBhTfEDY9BFOyxPTMzqwOeitd6z0BsY1qnQezsMf2S7P1yUX6fZeLXTC93B5Dc gflwbcNWun4OQ== Date: Tue, 26 Sep 2023 12:05:57 +0200 From: Christian Brauner To: Arnd Bergmann Cc: Miklos Szeredi , Miklos Szeredi , 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 , Ian Kent , David Howells , Linus Torvalds , Alexander Viro , Christian Brauner , Amir Goldstein Subject: Re: [RFC PATCH 2/3] add statmnt(2) syscall Message-ID: <20230926-kajak-klarzukommen-e6c6e3662798@brauner> References: <20230913152238.905247-1-mszeredi@redhat.com> <20230913152238.905247-3-mszeredi@redhat.com> <44631c05-6b8a-42dc-b37e-df6776baa5d4@app.fastmail.com> <20230925-total-debatten-2a1f839fde5a@brauner> <20230925-wahlrecht-zuber-3cdc5a83d345@brauner> <15fb406a-0f12-4708-abe7-91a464fecbc2@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <15fb406a-0f12-4708-abe7-91a464fecbc2@app.fastmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Mon, Sep 25, 2023 at 05:46:59PM +0200, Arnd Bergmann wrote: > On Mon, Sep 25, 2023, at 15:20, Miklos Szeredi wrote: > > On Mon, 25 Sept 2023 at 15:19, Christian Brauner wrote: > >> > >> > How about passing u64 *? > >> > >> struct statmnt_req { > >> __u64 mnt_id; > >> __u64 mask; > >> }; > >> > >> ? > > > > I'm fine with that as well. > > Yes, this looks fine for the compat syscall purpose. > > Not sure if losing visibility of the mnt_id and mask in ptrace > or seccomp/bpf is a problem though. It's an information retrieval syscall so there shouldn't be any need to block it and I think that this ship has sailed in general. Container workloads should migrate from seccomp to landlock if they need to filter system calls like this.