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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 67B2BC3F2D2 for ; Fri, 28 Feb 2020 12:27:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 38828246AC for ; Fri, 28 Feb 2020 12:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582892838; bh=m93yM93vQbcHMkGCkK/OGG8kf11IbeXU6ORroxAAGzo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=jOcmDrx2II+0FSxD0uVXjh72tzQzAjHgLatWzwG3YWK84c1qjnuClLSveYxbEKRCJ 95f4085FlI6zki3qGCEVPohXBITzJcSBUvhVRUz+5nDaugo0b71q4R2q4SQXLxrAKR Dyy/GEqRyAAu5mv+Kr9gMxiOrYZgBgYZSdzTZYWI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726094AbgB1M1R (ORCPT ); Fri, 28 Feb 2020 07:27:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:48882 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725802AbgB1M1R (ORCPT ); Fri, 28 Feb 2020 07:27:17 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1632D246A3; Fri, 28 Feb 2020 12:27:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582892834; bh=m93yM93vQbcHMkGCkK/OGG8kf11IbeXU6ORroxAAGzo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=1qkwABoJTSe5SmM+7+hNubXHM41yKugx1YRFHDmMnoOK5YYsRXnCmI+7Quf+GWlwi Bsu0HcZJviHZoYaZPpZHFb/vRkds/rPDV/VIY8AovPBUoT3uvbuxw3yFlFhMyyAs6G ZzL4KOs+fv5qzsr28SX0dPrQDm2L4JnAnSNwmRAM= Date: Fri, 28 Feb 2020 13:27:12 +0100 From: Greg Kroah-Hartman To: Miklos Szeredi Cc: Ian Kent , Karel Zak , Miklos Szeredi , James Bottomley , Steven Whitehouse , David Howells , viro , Christian Brauner , Jann Horn , "Darrick J. Wong" , Linux API , linux-fsdevel , lkml , Lennart Poettering , Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , util-linux@vger.kernel.org Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] Message-ID: <20200228122712.GA3013026@kroah.com> References: <1582644535.3361.8.camel@HansenPartnership.com> <1c8db4e2b707f958316941d8edd2073ee7e7b22c.camel@themaw.net> <3e656465c427487e4ea14151b77d391d52cd6bad.camel@themaw.net> <20200227151421.3u74ijhqt6ekbiss@ws.net.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 28, 2020 at 09:35:17AM +0100, Miklos Szeredi wrote: > On Fri, Feb 28, 2020 at 1:43 AM Ian Kent wrote: > > > > I'm not sure about sysfs/, you need somehow resolve namespaces, order > > > of the mount entries (which one is the last one), etc. IMHO translate > > > mountpoint path to sysfs/ path will be complicated. > > > > I wonder about that too, after all sysfs contains a tree of nodes > > from which the view is created unlike proc which translates kernel > > information directly based on what the process should see. > > > > We'll need to wait a bit and see what Miklos has in mind for mount > > table enumeration and nothing has been said about name spaces yet. > > Adding Greg for sysfs knowledge. > > As far as I understand the sysfs model is, basically: > > - list of devices sorted by class and address > - with each class having a given set of attributes Close enough :) > Superblocks and mounts could get enumerated by a unique identifier. > mnt_id seems to be good for mounts, s_dev may or may not be good for > superblock, but s_id (as introduced in this patchset) could be used > instead. So what would the sysfs tree look like with this? > As for namespaces, that's "just" an access control issue, AFAICS. > For example a task with a non-initial mount namespace should not have > access to attributes of mounts outside of its namespace. Checking > access to superblock attributes would be similar: scan the list of > mounts and only allow access if at least one mount would get access. sysfs does handle namespaces, look at how networking does this. But, it's not exactly the simplest thing to do so, so be careful with that as this is going to be essential for this type of work. thanks, greg k-h