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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 F24E4C3F2D0 for ; Fri, 28 Feb 2020 08:35:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CA539246A2 for ; Fri, 28 Feb 2020 08:35:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="pn3452AK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726525AbgB1If3 (ORCPT ); Fri, 28 Feb 2020 03:35:29 -0500 Received: from mail-il1-f194.google.com ([209.85.166.194]:44280 "EHLO mail-il1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726287AbgB1If3 (ORCPT ); Fri, 28 Feb 2020 03:35:29 -0500 Received: by mail-il1-f194.google.com with SMTP id x7so2002972ilq.11 for ; Fri, 28 Feb 2020 00:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OXyFeX6mAXl7ibpfgMxisE4ycSpVpmIz9s5cjNf8Vhw=; b=pn3452AKsTBvGlo0Y5JA0NZltS3uiCzuNxlOu9vIU/91jdvfz1MmnUcdniXZft8fOK uRgelnJFXnk/5446/FJEkurj9vFQkfopb6YzN9hGnaI6ygpIsXBuRwoK4kfbvuwENiZZ 0wpCmRg1DtQDcyWKqHDbVr5FOAQOpPzh6yVGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OXyFeX6mAXl7ibpfgMxisE4ycSpVpmIz9s5cjNf8Vhw=; b=olydI646usE7FxlE2qPwdO3JP/4NR1eo8C+Nm9LkmIpkzFYvb+IhRpicoMBNjuUCRv TEzbneW6evL+swY00pehnV/QLgO9Of89A5XzyitLjH+GG+ElBOd2d4iVD+tvk1K5/S14 xaZRVL1TZS5NpU19MkQHZjZ83bu/GcgCdhuUY4l9RkKmoCN4x0y2F3F8xWZX5kOg4rfN kMAbNYaBIBHx409WtVSGJ7G0KWvDIdRuNsS1l4Vy9NWQ0YgLdsOPlpzBoE/teS7eOsQM 0D9fmNzXFeccROgO6DeG4UIvTYXvAg7T1GIgY/U4SQnVYIWzgKGY+BC4cweHA78mxway Am3Q== X-Gm-Message-State: APjAAAUdgoxQnH6qBBdowRmfSl7HAy0xWtzBaB0TfKnjjwgIr0fDHUO6 /VynHcyCfxR1WQajAnebYlIBHHMsNqMKWqfxfXm8Hg== X-Google-Smtp-Source: APXvYqxjtpW0+aq1pP5LqW+8ExOWmG1iZmCw8TTmpTp910yfA5bDPzQCZIQLWAdbpcyM6H+iB+v7QzmYJWaDKFsm31s= X-Received: by 2002:a92:c0c9:: with SMTP id t9mr3379386ilf.174.1582878928605; Fri, 28 Feb 2020 00:35:28 -0800 (PST) MIME-Version: 1.0 References: <1582556135.3384.4.camel@HansenPartnership.com> <1582644535.3361.8.camel@HansenPartnership.com> <1c8db4e2b707f958316941d8edd2073ee7e7b22c.camel@themaw.net> <3e656465c427487e4ea14151b77d391d52cd6bad.camel@themaw.net> <20200227151421.3u74ijhqt6ekbiss@ws.net.home> In-Reply-To: From: Miklos Szeredi Date: Fri, 28 Feb 2020 09:35:17 +0100 Message-ID: Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] To: Ian Kent Cc: 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 , =?UTF-8?Q?Zbigniew_J=C4=99drzejewski=2DSzmek?= , Greg Kroah-Hartman , util-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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 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. 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. > While fsinfo() is not similar to proc it does handle name spaces > in a sensible way via. file handles, a bit similar to the proc fs, > and ordering is catered for in the fsinfo() enumeration in a natural > way. Not sure how that would be handled using sysfs ... I agree that the access control is much more straightforward with fsinfo(2) and this may be the single biggest reason to introduce a new syscall. Let's see what others thing. Thanks, Miklos