You're right, and I've changed all the references to roles in the proposal to "permission groups".
> 2. "The first rule ... has an action ('allow'), a subject ('all users'), and a predicate ('read')"
I've changed this bit by referring to these things respectively as an "action", a "principal" and a "permission" to avoid mangling the abstract concepts of all languages. ;-)
> 3. "The last rule ... ("deny access to all users") is implied" Why? Why not make it explicit?
There can only be two outcomes during the checking of an ACL... allow or deny. But no ACE is guaranteed to "match" during ACL checking. Something needs to happen if all ACEs in an ACL fail to generate an allow or deny during enforcement. This something is currently "deny". The only other possible choice is "allow". It's probably easier to instruct users to create an ACL at the root of the hierarchy that had as its last rule "allow all from everyone" and instruct them to maintain this ACE in the rest of the ACLs in hierarchy via "static inheritance" instead of making this pluggable in Decsec.
> 4. I imagine that many applications are going to want to have ACLs "inherited" and "overridden"
> (but then you are basically back to Zope's model).
This is accounted for in the sections entitled "associating ACLs with Paths (via a GUI|Programmatically)". The difference between Decsec and Zope is that the inheritance and overriding does not happen during traversal but during the change of ACL in a node which has subnodes statically.
One of the things I failed to mention is that when you create an ACL for a subnode, the "default" ACL definition you are presented with while doing this interactively is the ACL that is found in its parent (or higher if the parent for some reason has no ACL).
FWIW, I'm not really *enthused* about the "static ACL" model. It actually creeps me out a little bit because like everybody I've been at a Windows system where I change an ACL somewhere low in the hierarchy and need to wait for two or three minutes while it merges the ACL statically into the ACL of all subfolders. That said, ACLs *in general* feel like the most flexible model and they solve in a very general way some problems with the existing Zope 2 security machinery (like denying access in a certain place, solved with hacks like a local role blacklist) but they might not need to be static. But instead of completely static ACLs, I suppose a model of "dynamically compose an ACL out of grants and denies during traversal" could be used instead to the same effect. The things I *do* like about static ACLs is they are a) easy to code up b) nominally faster to compute during traversal and c) provide an obvious, unambiguous failure point when you're trying to debug a security problem (see the "Auditing and Debugging" section of the proposal).
> 5. "Zope's internal security machinery controls access to objects." True for Zope2; Zope3 protects
> "names", not objects, and does so at each 'getattr' (via security proxies).
The point I was trying to make was that policies are attached in one way or another to objects in Zope and I've changed the proposal to reflect that. I know this is true for Zope 2 and, by default at least via permission annotations for Zope 3.
> 5. "Zope's security machinery enforces its security policy during traversal." For clarity:
> in Zope2, this statement is true, *except* during "publishing" traversal
Yep, I've changed the proposal to read "during or after".
Thanks a lot for reading, it couldn't have been easy. ;-)
> 1. "A role is a collection of permissions"
You're right, and I've changed all the references to roles in the proposal to "permission groups".
> 2. "The first rule ... has an action ('allow'), a subject ('all users'), and a predicate ('read')"
I've changed this bit by referring to these things respectively as an "action", a "principal" and a "permission" to avoid mangling the abstract concepts of all languages. ;-)
> 3. "The last rule ... ("deny access to all users") is implied" Why? Why not make it explicit?
There can only be two outcomes during the checking of an ACL... allow or deny. But no ACE is guaranteed to "match" during ACL checking. Something needs to happen if all ACEs in an ACL fail to generate an allow or deny during enforcement. This something is currently "deny". The only other possible choice is "allow". It's probably easier to instruct users to create an ACL at the root of the hierarchy that had as its last rule "allow all from everyone" and instruct them to maintain this ACE in the rest of the ACLs in hierarchy via "static inheritance" instead of making this pluggable in Decsec.
> 4. I imagine that many applications are going to want to have ACLs "inherited" and "overridden"
> (but then you are basically back to Zope's model).
This is accounted for in the sections entitled "associating ACLs with Paths (via a GUI|Programmatically)". The difference between Decsec and Zope is that the inheritance and overriding does not happen during traversal but during the change of ACL in a node which has subnodes statically.
One of the things I failed to mention is that when you create an ACL for a subnode, the "default" ACL definition you are presented with while doing this interactively is the ACL that is found in its parent (or higher if the parent for some reason has no ACL).
FWIW, I'm not really *enthused* about the "static ACL" model. It actually creeps me out a little bit because like everybody I've been at a Windows system where I change an ACL somewhere low in the hierarchy and need to wait for two or three minutes while it merges the ACL statically into the ACL of all subfolders. That said, ACLs *in general* feel like the most flexible model and they solve in a very general way some problems with the existing Zope 2 security machinery (like denying access in a certain place, solved with hacks like a local role blacklist) but they might not need to be static. But instead of completely static ACLs, I suppose a model of "dynamically compose an ACL out of grants and denies during traversal" could be used instead to the same effect. The things I *do* like about static ACLs is they are a) easy to code up b) nominally faster to compute during traversal and c) provide an obvious, unambiguous failure point when you're trying to debug a security problem (see the "Auditing and Debugging" section of the proposal).
> 5. "Zope's internal security machinery controls access to objects." True for Zope2; Zope3 protects
> "names", not objects, and does so at each 'getattr' (via security proxies).
The point I was trying to make was that policies are attached in one way or another to objects in Zope and I've changed the proposal to reflect that. I know this is true for Zope 2 and, by default at least via permission annotations for Zope 3.
> 5. "Zope's security machinery enforces its security policy during traversal." For clarity:
> in Zope2, this statement is true, *except* during "publishing" traversal
Yep, I've changed the proposal to read "during or after".
Thanks a lot for reading, it couldn't have been easy. ;-)