On Oct 30, 2009, at 7:54 AM, Michael Meffie wrote:
Hello, Andrew, Tom, and I would like to discuss and solicit feedback on some ideas we have been considering to strengthen OpenAFS access controls, especially for sites which provide AFS service over the public internet.
I like the additional capabilities offered by this concept. In one of my past lives I had a requirement (which went unfilled) for such controls. The examples you gave made sense, except that there seems to be a hole.
We need to take into consideration nested groups (aka supergroups). For example, assume for some reason, the group system:anyuser is a member of the group project:mayhem. This creates a complication in that a user could set the ACLs for project:mayhem, and transitively effect members of system:anyuser. Consider a volume called project.mayhem, which is mounted at as /afs/example.com/project/mayhem. setpolicy -grant -user system:anyuser -set-rights rl -for-user system:anyuser -in-volume project.mayhem pts adduser example:staff project:mayhem pts adduser system:anyuser project:mayhem Since the pts group system:anyuser now a member of the project:mayhem group, then the setting of the ACLs for project:mayhem would also need to be restricted, cd /afs/example.com/project fs setacl mayhem project:secret rlidwk
I think you meant "fs setacl mayhem project:mayhem rlidwk"
fs: You don't have the required access rights on mayhem
I don't think you've solved this part of the problem. I don't know how to solve it, either.
Since the restrictive policy on adding ACLs is evaluated at the time that the ACL is modified, and the membership of the super-group can be modified either before or after that event, this approach isn't going to result in any reasonable level of assurance that the ACLs are enforcing the intended policy (regarding access to the filesystem). It seems that as long as supergroups are in use in the cell, this is a potential hole.
In fact, this same issue exists with respect to individual members of a normal group as well. (A policy preventing people from giving jane write access to some object would be circumvented if jane was added after the fact to a group that is allowed to be given write access to that object.)
_______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
