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.
