Re: A pass-through support for NFSv4 style ACL

[Theodore Ts'o]

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....

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.

Personally, I think this is rarely needed, since (a) most people
implementing a Windows-style filer for Windows client are doing so on
a dedicated file server, and local access to the exported files are
rarely needed.  Secondly, (b) Windows-style access need to be
expressed in terms of Windows-style Security ID's for large complex
enterprise deployment where you have nested Windows-style domains, and
how you map a 128+ bit Windows SID to a local Unix UID is a previously
unsolved problem.

So it's a pretty rare niche use case, and *I've* never thought that
this is all that important.  On the other hand, for those people who
believe that "This is the year of the Linux Desktop", and who might
want to export their local Linux directories on their Desktop to a set
of peer Windows clients, and who are using complex Windows-style ACL's
(but not *too* complex such that they have nested domain identifiers),
then RichACL's might be just the ticket.  Furthermore, RichACL's are
apparently an out-of-tree patch maintained by some distros in their
distro kernel, so maybe they know something I don't.

Add to that the issues of the implementation level concerns which
Cristoph has already described, and it's really not all that
surprising that the progress on the patchset kind of stalled....

	   	    	     	    - Ted