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 for Android: free password hash cracker in your pocket

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

Message-ID: <39284de5-8eb8-ba1d-7ea6-be9b9b5df42c@redhat.com>
Date:   Wed, 26 Feb 2020 10:51:00 +0000
From:   Steven Whitehouse <swhiteho@...hat.com>
To:     Miklos Szeredi <mszeredi@...hat.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Miklos Szeredi <miklos@...redi.hu>,
        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 26/02/2020 09:11, Miklos Szeredi wrote:
> On Tue, Feb 25, 2020 at 4:29 PM James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
>
>> The other thing a file descriptor does that sysfs doesn't is that it
>> solves the information leak: if I'm in a mount namespace that has no
>> access to certain mounts, I can't fspick them and thus I can't see the
>> information.  By default, with sysfs I can.
> That's true, but procfs/sysfs has to deal with various namespacing
> issues anyway.  If this is just about hiding a number of entries, then
> I don't think that's going to be a big deal.
>
> The syscall API is efficient: single syscall per query instead of
> several, no parsing necessary.
>
> However, it is difficult to extend, because the ABI must be updated,
> possibly libc and util-linux also, so that scripts can also consume
> the new parameter.  With the sysfs approach only the kernel needs to
> be updated, and possibly only the filesystem code, not even the VFS.
>
> So I think the question comes down to:  do we need a highly efficient
> way to query the superblock parameters all at once, or not?
>
> Thanks,
> Miklos
>

That is Ian's use case for autofs I think, and it will also be what is 
needed at start up of most applications using the fs notifications, as 
well as at resync time if there has been an overrun leading to lost fs 
notification messages. We do need a solution that can scale to large 
numbers of mounts efficiently. Being able to extend it is also an 
important consideration too, so hopefully David has a solution to that,

Steve.