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
