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
>> 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
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.
However, security related rules are important enough that
they deserve thourough and prominent specification/documentation.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -