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).
I don't see this as blurred at all. A sequence is, mathematically, a special case of a mapping.
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 question whether there is a need to check "whether access should be granted to individual items in a mapping".
I suggest that such flexibility makes the security system needlessly complex.
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.
Ah, so you are arguing that the handler should simply not be called for item access. I can buy that. I don't think that would make Stuart happy though. :)
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 assume that you are refering to the security policy.
* 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.
These are valid points. This should be documented much better than it has been. I'll note that both of the things you ask about relate to no-longer used features of the security policy.
I'll make an attempt at a brief explanation:
- The *original* reason for the accessed and validate parameters was to permit the distinction between acquired and non-acquired attributes. As a comment in the security policy code notes, we no-longer pay any attention to the accessed argument.
- The *original* use for the 0 return value from the security policy was to suggest that, although access to the value provided was unauthorized, the application might provide a different value that would be. This was to support a questionable feature of trying to acquire another value of the first value found through acquisition was unauthorized. The current Zope security policy never returns 0.
Much of the complexity in the Zope 2 security policy has to do with:
- The fact that the security system is based on looking at assertions for values, and
- The fact that we can't make assertions on immutable values (e.g. strings).
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?
In Zope 3 (and, I hope 2.9), it will be easier to make security assertions about things you can't make assertions about now.
The fundamental change in Zope 3 is that we make assertions about *names*, not values. This makes it possible to talk about access to attributes whose values are strings. Essentially, we are placing the resytictions on the *access*, not the values.
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).
A mistake in Zope 2, we've made the mistake of trying to provide backward compatability at almost any cost. This has led to parts of the framework being far more complicated than it should be.
In the future, we've got to do a better job of managing change so that we can clean things up.
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.
However, security related rules are important enough that they deserve thourough and prominent specification/documentation.
Yup. We are certainly trying to do a good job of this in Zope 3. I hope that, in the near furture, we can merge some aspects of the Zope 2 and Zope 3 security architectures.
-- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce