Rich access control lists

Posted Aug 15, 2019 17:59 UTC (Thu) by pgoetz (subscriber, #4931)
In reply to: Rich access control lists by skissane
Parent article: Rich access control lists

An example is provided here: https://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03...

There is one extremely minor inaccuracy in this mapping: if a
requester that is a member of more than one group listed in the ACL
requests multiple bits simultaneously, the POSIX algorithm requires
all of the bits to be granted simultaneously by one of the group
ACEs. Thus a POSIX ACL such as

ACL_USER_OBJ: ---
ACL_GROUP_OBJ: ---
g1: r--
g2: -w-
ACL_MASK: rw-
ACL_OTHER: ---

will prevent a user that is a member of groups g1 and g2 from opening
a file for both read and write, even though read and write would be
individually permitted.

The NFSv4 ACL permission-checking algorithm has the property that it
permits a group of bits whenever it would permit each bit individu-
ally, so it is impossible to mimic this behaviour with an NFSv4 ACL.

Rich access control lists

Posted Aug 15, 2019 18:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

A great example why RichACLs and ACLs in general are a bad idea and should just stay away from the kernel.

Rich access control lists

Posted Aug 20, 2019 16:43 UTC (Tue) by bfields (subscriber, #19510) [Link]

Eh, this is a pretty minor nit.

If you want to complain about some flavor or ACLs being too complicated, I think there are better places to start.

Here, honestly, I think we should probably just fix the Linux ACL implementation, and I doubt anyone would notice the change.

I've been meaning to write a patch and just haven't gotten around to it. It's not something people run across in practice so a little hard to prioritize.