Dieter Maurer wrote:
Jim Fulton wrote at 2003-11-13 15:22 -0500:
> ...
> We need to refactor the way security assertions (permission
> settings) are stored and accessed. We need to store required
> permissions (__permissions__) on objects. When we need to figure
> out roles, we need to compute them at a higher level. (For
> example, we could compute the needed roles in the zope security
> policy It's likely that we can speed security checks when doing
> this.)
> > I estimate that the necessary refactoring would take me 3-5
> days. The vast majority of the required time will be spent writing
> tests. I really need to focus on Zope 3 for a while, so I may not
> be able to get back to this soon. I think that this is an area
> where some volunteers could make a big difference. I'd be happy to
> work with some folks on this.

Folklore says that Zope cannot protect attributes of simple types
(because they do not provide the method magic that will be lost
for NSEC).

From your patch, I think you are talking about protection of attributes of non-simple types whose values are not simple types. That is, protecting the title attribute of a folder even though the value of the attribute is a string and thus, can't be assigned a __roles__ attribute.

However, whenever I looked at ZopeSecurityPolicy (and I did often),
I could not believe that this is true. I always thought, it would
be easy to provide security declarations for simple type attributes, too.

Of course, Zope cannot check a bare value of simple type, but
usually it has "container" and/or "parent" and then checking would
be easy by looking at related ("__roles__") attributes of the container/parent.

I will see this weekend whether I have been true.
If so, the same mechanism could (in principle) be used for

Bound methods can even be checked without "container/parent"
as they allow access to the bound instance.

And a day later, Dieter Maurer wrote: > Patch attached.

So, when we are accessing a named attribute and the value doesn't
have security data, look for security data on the object we got it
from.  I like the general idea.

Hm, I suppose that this would let us keep the __roles__ travesty for now,
which would allow us to proceed with 2.8 without doing the refactoring now.

Very nice. (well, sort of ;)

I'll see if this idea lets me get the "devil branch" merged to the trunk next
week. (I need to make the next Z3 milestone release first.)


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to