David R. Baird wrote:
I think the treeness is quite important, because groups inherit the capabilities/permissions of their subgroups. So whenever you check if your own group is permitted to do something, you know that the tree-
like hierarchy of groups contained within your group is also being checked.
"Group", by itself, infers no such treeness. You may have chosen to model your groups and users by some close analogue of;
+-----------------+ +---------+ +--------+
| GrantableEntity |------| Grant |------| Entity |
+--------+--------+ 1 * +---------+ * 1 +--------+
/_\
|
+---+ +---------+--------+
| | * | |
|* +---------+ * * +--------+
+--| Group |---------| User |
+---------+ +--------+
Unix Groups, for instance, do not bother with this, so "Group" doesn't mean "Heirarchy of Groups" in this case.
The problem with these such discussions is that such a wide variety of possible ACL structures are all used and called "ACLs" - though each can have a different arrangement of explicit or implied inheritance between security objects, and multiplicity of each relationship. So, they have different properties, which is easy to see when they are expressed in UML, as above.
Some people even try to express one particular concrete form or describe a design-specific property, and call that structure the definition of the term. In the end, as long as there is a virtual concept of controlling access, it can be called an ACL. You could call Unix Groups an ACL mechanism, and it would not be incorrect.
UML is an excellent language with which to express the exact nature of the ACL that your module implements. _*The Art of Objects: Object-Oriented Design and Architecture_, by *Yun-Tung Lau <http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Yun-Tung%20Lau/102-5857950-6496945> (isbn://0201711613/) uses ACL design as one of its worked examples. Highly recommended.
-- Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
