Andreas Grünbacher <andreas.gruenbacher@xxxxxxxxx> writes: > 2016-09-21 17:40 GMT+02:00 Eric W. Biederman <ebiederm@xxxxxxxxxxxx>: >> Miklos Szeredi <miklos@xxxxxxxxxx> writes: >>> 3) How will richacl's fit into this? >> >> As best as I can read the situation richacl support has not yet been >> merged into Linux yet. > > True. The patches are stuck in Al Viro's inbox since a very long time. > >> Last I was following the richacl discussion there were some fundamental >> features of richacls that were incompatible with the expectations of >> ordinary linux applications. > > Not true. > >> The negative acls if my memory serves. >> That raised some concern if richacls could ever be safely be merged. >> >> As I recall Christoph Hellwig was a primary on raising those concerns, >> and when I read those arguments they seemed persuasive to me. > > The whole point of Richacls is to be compatible with the POSIX file > permission model. Entries that deny permissions are a necessary part > of Richacls for various reasons. Christoph doesn't like them, but that > doesn't make them any less necessary. Negative access control permissions are extremly nasty, and cause a lot of problems in the real world, especially where they have not existed before. And sometimes where they are rare enough to not have existed before. I am would prefer you taking a measured approach rather than ignoring people's concerns. I certainly don't need any kind of ACLs for any kind of files I have ever dealt with in practice. I deal with ACLs and make certain the kernel supports them well to ensure there are not nasty bugs waiting in the wings. If my memory serves there are very funny corner cases between negative uids ACLs and user namespaces. The kind that can lead to security vulnerabilities etc. The practical problem I would envision is users using user namespaces to enable them to change their uid or gid and that in turn would result in negative acls failing to contain deny users access to files. So I would be very careful with adding negative permission checks that are going to be (at best) very error prone to use to the current unix permission model. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
