2016-09-21 19:42 GMT+02:00 Eric W. Biederman <ebiederm@xxxxxxxxxxxx>: > 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. Not sure what you're trying to say with that last sentence. But anyway, let me cure you from the myth that "negative permmissions" don't exist in the traditional UNIX permission model: when the owner is assigned fewer permissions than the owning group (for example, mode 044), or the owning group is assigned fewer permissions than others (for example, mode 604), particular users have fewer permissions than others by virtue of their identity. That property is just expressed differently in the traditional UNIX permission model and in Richacls. By the way, here is Christoph's complaint that you're probably referring to, and my reply: http://oss.sgi.com/archives/xfs/2016-03/msg00207.html http://oss.sgi.com/archives/xfs/2016-03/msg00219.html There was no further follow-up by Christoph. > I am would prefer you taking a measured approach rather than ignoring > people's concerns. I've long thought about this, and documented and argued why removing deny ACEs wouldn't make sense. If you think otherwise, come up with convincing technical arguments. > 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. See above for how it's possible to shoot yourself in the foot in that way with namespaces already. Andreas -- 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
