linux-kernel - Re: A pass-through support for NFSv4 style ACL

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]

Date:   Fri, 19 May 2023 12:56:55 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Jeff Layton <jlayton@...nel.org>,
        Ondrej Valousek <ondrej.valousek.xm@...esas.com>,
        "trondmy@...merspace.com" <trondmy@...merspace.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: A pass-through support for NFSv4 style ACL

On Wed, May 17, 2023 at 08:39:14AM -0400, Theodore Ts'o wrote:
> On Wed, May 17, 2023 at 09:42:59AM +0200, Christian Brauner wrote:
> > 
> > I have no idea about the original flame war that ended RichACLs in
> > additition to having no clear clue what RichACLs are supposed to
> > achieve. My current knowledge extends to "Christoph didn't like them".
> 
> As to what RichACL's are supposed to achieve....

Interesting, thanks for all the details!

> 
> Windows/NFSv4 -style ACL's are very different from POSIX semantics, in
> a gazillion ways.  For example, if you set a top-level acl, it will
> automatically affect all of the ACL's in the subhierarcy.  This is
> trivially easy in Windows given that apparently ACL's are evaluated by
> path every time you try to operate on a file (or at least, that's how
> it works effectively; having not taken a look at Windows source code,
> I can't vouch for how it is actually implemented.)  This is, of
> course, a performance disaster and doesn't work all that well for
> Linux where we can do things like like fchdir() and use O_PATH file
> descriptors and *at() system calls.  Moreover, Windows doesn't have
> things like the mode parameter to open(2) and mkdir(2) system calls.
> 
> As a result, RichACL's are quite a bit more complicated than Posix
> ACL's or the Windows-style ACL's from which they were derived because
> they have to compromise between the Windows authorization model and
> the Posix/Linux authorization model while being expressive enough
> to mostly emulate Windows-style ACL's.  For example, instead of
> implementing Windows-style "automatic inheritance", setrichacl(1) will
> do the moral equivalent of chmod -R, and then add a lot of hair in the
> form of "file_inherit, dir_inherit, no_propagate, and inherit_only"
> flags to each ACL entry, which are all there to try to mostly (but not
> completely) handle make Windows-style and Linux/POSIX acl's work
> within the same file system.  There's a lot more detail of the hair
> documented here[1].
> 
> [1] https://www.systutorials.com/docs/linux/man/7-richacl/
> 
> I'll note most of this complexity is only necessary if you want to
> have local file access to the file system work with similar semantics
> as what would get exported via NFSv4.  If you didn't, you could just
> store the Windows-style ACL in an xattr and just let it be set via the
> remote file system, and return it when the remote file system queries
> it.  The problem comes when you want to have "RichACLs" actually
> influence the local Linux permissions check.

Yeah, I'm already scared enough.