Jim Fulton wrote at 2004-1-16 18:54 -0500:
...
For security checks, the accessed object should be the driving factor and not the particular way the access is made.
Well, sorry, that's not what this is about. We are talking about what to do when accessing objects without roles. The ability to take the name into account is a feature that only makes sense for named, ie attribute access, imo.
"item" is a blurred term in Python: As you know, it refers both to sequences (indexed via integers) and mappings (indexed via something hashable; often a string). When some mechanism checks whether access should be granted to individual items in a mapping, this mechanism will (almost surely) need to know the key used in the access -- and I do not see any reason why it should not be informed about the key. I do not argue that the handler registered with "setDefaultAccess" should be used for "__getitem__" access checking. However, when it is called (as it seems to be the case), then it should be called consistently and provide as much information as useful -- this includes information about both arguments to the "__getitem__" method. Even more essential for security related issues: A precise description when what security related functions are called with what arguments. The current state in this respect is far from optimal. Special points of my concern: * I never saw a description of the difference between the "accessed" and "container" parameters to "validate". * I never saw a description for the three way outcome of "validate": "0", "1" and "raise Unauthorized". Why in hell is "unauthorized" encoded sometimes as "return 0" and sometimes as "raise Unauthorited". Looking at the code, I see that "accessed/container" has to do with this destinction. However, as "accessed/container" is unspecified, this does not clarify much.
When we do not get this consistent, we open new hidden security holes (as one must always think: can this same object be accessed also in a different way and how have I to secure this way).
Certainly, you have to think about how you provide access to data. Lots of data we provide access to has no security assertions of it's own.
Maybe, we should change this for Zope 3? It would have been possible for Zope 2 since a long time -- but tightening security has high risk to break many applicitation (as the latest security fixes demonstrated again).
Think of accessor methods that return data. If data needs to be protected, you need to think about the access methods you provide.
In the future, item access will work like this:
You will be able to protect __setitem__ operations. Once someone can use setitem, they can access any key. The value stored with that key may have pretections of it's own, or not. That's a matter of application design.
Fine! However, security related rules are important enough that they deserve thourough and prominent specification/documentation. -- Dieter