Re: A pass-through support for NFSv4 style ACL

From: Christian Brauner
Date: Fri May 19 2023 - 06:57:06 EST


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.