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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )