linux-kernel - Re: [PATCH 11/19] afs: Support fsinfo() [ver #16]

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: <CAG48ez03VMKEmJEmViSkxbF9J5dW=6vny9vKGdenBewtjF+nqQ@mail.gmail.com>
Date:   Thu, 20 Feb 2020 15:58:10 +0100
From:   Jann Horn <jannh@...gle.com>
To:     David Howells <dhowells@...hat.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>, raven@...maw.net,
        Miklos Szeredi <mszeredi@...hat.com>,
        Christian Brauner <christian@...uner.io>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 11/19] afs: Support fsinfo() [ver #16]

On Thu, Feb 20, 2020 at 1:59 PM David Howells <dhowells@...hat.com> wrote:
> Jann Horn <jannh@...gle.com> wrote:
>
> > Ewww. So basically, having one static set of .fsinfo_attributes is not
> > sufficiently flexible for everyone, but instead of allowing the
> > filesystem to dynamically provide a list of supported attributes, you
> > just duplicate the super_operations? Seems to me like it'd be cleaner
> > to add a function pointer to the super_operations that can dynamically
> > fill out the supported fsinfo attributes.
> >
> > It seems to me like the current API is going to be a dead end if you
> > ever want to have decent passthrough of these things for e.g. FUSE, or
> > overlayfs, or VirtFS?
>
> Ummm...
>
> Would it be sufficient to have a function that returns a list of attributes?
> Or does it need to be able to call to vfs_do_fsinfo() if it supports an
> attribute?
>
> There are two things I want to be able to do:
>
>  (1) Do the buffer wrangling in the core - which means the core needs to see
>      the type of the attribute.  That's fine if, say, afs_fsinfo() can call
>      vfs_do_fsinfo() with the definition for any attribute it wants to handle
>      and, say, return -ENOPKG otherways so that the core can then fall back to
>      its private list.
>
>  (2) Be able to retrieve the list of attributes and/or query an attribute.
>      Now, I can probably manage this even through the same interface.  If,
>      say, seeing FSINFO_ATTR_FSINFO_ATTRIBUTES causes the handler to simply
>      append on the IDs of its own supported attributes (a helper can be
>      provided for that).
>
>      If it sees FSINFO_ATR_FSINFO_ATTRIBUTE_INFO, it can just look to see if
>      it has the attribute with the ID matching Nth and return that, else
>      ENOPKG - again a helper could be provided.
>
> Chaining through overlayfs gets tricky.  You end up with multiple contributory
> filesystems with different properties - and any one of those layers could
> perhaps be another overlay.  Overlayfs would probably needs to integrate the
> info and derive the lowest common set.

Hm - I guess just returning a list of attributes ought to be fine?
Then AFS can just return one of its two statically-allocated attribute
lists there, and a filesystem with more complicated circumstances
(like FUSE or overlayfs or whatever) can compute a heap-allocated list
on mount that is freed when the superblock goes away, or something
like that?