[Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py

[Jim Fulton]

Stuart Bishop wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 16/01/2004, at 9:23 AM, Jim Fulton wrote:
> 
>> Dieter Maurer wrote:
>>
>>> Jim Fulton wrote at 2004-1-15 10:03 -0500:
>>>
>>>> ...
>>>> Right. The name attribute was intended for attribute-based access.
>>>>
>>>> IMO, it makes no sense to consider key values when doing security
>>>> checks.
> 
> 
> I had thought we had more,

More what?

> but most of that logic is now in
> a ComputedAttribute __ac_local_roles__ and in our __getitem__
> hooks. What we currently have is a BTree storing key -> value.
> Valid keys are defined by a schema. If that schema changes, we
> do not want to lose the information until we are sure it has
> been archived, but we no longer want it available.
> 
> The sorts of things we *were* doing was allowing access to
> certain attributes

I'm confused.  Attributes of what? Above you are refering to
a BTree.

> if the currently authenticated user had
> required permissions on a related object.
> 
>     eg. A bag-of-metadata has an associated Publisher object,
>         and the Publisher has Editors (implemented as a local
>         role assigned in the Publisher). Access to bits of
>         metadata would be calculated based on the bag's schema,
>         which determined if each bit was private, public or shared.
>         Shared was available to people with certain permissions
>         on the bag, or to people with certain permissions on the
>         associated Publisher (the Editors). Some metadata has
>         calculated privacy settings (eg. EmailAddress is shared
>         or public depending on the value of PrivateEmailAddress)
> 
> We now have the situation that this is possible if bag-of-metadata
> is accessed via getattr (stored as attributes on the object),
> but not via getitem (stored anywhere else).

My suggestion would be to wrap the BTree in an object that accesses
it via getattr.

> I can also imagine BTrees keyed to userid (eg storing settings),
> where people can only access their branch or branches of people
> in their workgroup.

Sure, but, presumably, these settings would be objects that would
have p[rotections defined for their attributes.

>> BTW, telling me that an algorithm has changed doesn't constitute
>> a use case. :) I know that algorithm has changed.  I assert that
>> we don't need the feature that the change broke.  I am open
>> to evidence to the contrary.
> 
> 
> Its probably a feature we don't *need*, but some of us happen
> to be using it, and have been using this documented feature
> since Zope 2.5.

Where is it documented? I did a quick look, and couldn'd find documentation
of this feature.

> I can probably work around it (although it
> means the next milestone release next week will be on b3
> instead of b4), but I'd assumed that if one person who
> is using the beta triggered this issue, there will be plenty
> more who may be upset when they try porting their apps to 2.7.0
> release.


Treating item access and attribute access the same way has some inherent
problems.  We ran into this in the security work. We needed to provide
protection for some methods on lists and dictionaries.  when we implemented
this, we found we could no-longer access their items.

It was never intended that the ability to control unprotected sub-objects
by name would apply to items.  It was sloppy coding on my part that item indexes
(yes, indexes, like, say, 1) and keys were passed as names.  I can certainly
understand why people looking at the code and trying things out would come
to the wrong conclusion.

Fundamentally, it's wrong to use the same mechanism for attributes and
item keys or indexes.  In the recent security work, we tried to address
this by not passing the name for for item access. Unfortunately, this broke
some code.  I *think* that there cannot be too many cases of this.

I I'm pretty sure that I can redo the way we protect dictionaries and
lists so that we can provide backward compatability.  If I can do this,
I will, because backward compatability *is* important, especially for bug-fix
releases.

I'll say, however that this "feature" should be considered deprecated.
We will *not* allow you to control access based on item keys or indexes
in Zope 3.  I *hope* to merge the Zope 2 and Zope 3 protection schemes in
Zope 2.9, so you should expect this feature to go away in Zope 2.9.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org