linux-kernel - Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a657a80e-8913-d1f3-0ffe-d582f5cb9aa2@redhat.com>
Date:   Tue, 25 Feb 2020 12:13:11 +0000
From:   Steven Whitehouse <swhiteho@...hat.com>
To:     Miklos Szeredi <miklos@...redi.hu>,
        James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Miklos Szeredi <mszeredi@...hat.com>,
        David Howells <dhowells@...hat.com>,
        viro <viro@...iv.linux.org.uk>, Ian Kent <raven@...maw.net>,
        Christian Brauner <christian@...uner.io>,
        Jann Horn <jannh@...gle.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver
 #17]

Hi,

On 24/02/2020 15:28, Miklos Szeredi wrote:
> On Mon, Feb 24, 2020 at 3:55 PM James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
>
>> Once it's table driven, certainly a sysfs directory becomes possible.
>> The problem with ST_DEV is filesystems like btrfs and xfs that may have
>> multiple devices.
> For XFS there's always  a single sb->s_dev though, that's what st_dev
> will be set to on all files.
>
> Btrfs subvolume is sort of a lightweight superblock, so basically all
> such st_dev's are aliases of the same master superblock.  So lookup of
> all subvolume st_dev's could result in referencing the same underlying
> struct super_block (just like /proc/$PID will reference the same
> underlying task group regardless of which of the task group member's
> PID is used).
>
> Having this info in sysfs would spare us a number of issues that a set
> of new syscalls would bring.  The question is, would that be enough,
> or is there a reason that sysfs can't be used to present the various
> filesystem related information that fsinfo is supposed to present?
>
> Thanks,
> Miklos
>
We need a unique id for superblocks anyway. I had wondered about using 
s_dev some time back, but for the reasons mentioned earlier in this 
thread I think it might just land up being confusing and difficult to 
manage. While fake s_devs are created for sbs that don't have a device, 
I can't help thinking that something closer to ifindex, but for 
superblocks, is needed here. That would avoid the issue of which device 
number to use.

In fact we need that anyway for the notifications, since without that 
there is a race that can lead to missing remounts of the same device, in 
case a umount/mount pair is missed due to an overrun, and then fsinfo 
returns the same device as before, with potentially the same mount 
options too. So I think a unique id for a superblock is a generically 
useful feature, which would also allow for sensible sysfs directory 
naming, if required,

Steve.