[Zope-dev] strange priv leak

[Shane Hathaway]

Paul Winkler wrote:
> On Mon, May 19, 2003 at 12:34:44PM -0400, Shane Hathaway wrote:
> 
>>The same thing changed for integers and strings (and probably all other 
>>built-in types).  The __doc__ check has always been hackish anyway.  Ideas?
> 
> 
> start declaring security on stuff that's traditionally
> relied on having no docstring?

We can't, unless we overhaul the security policy.  Declarations for 
built-in types get ignored.  This is because the security policy depends 
on being able to find a __roles__ attribute on the thing accessed. 
Instances of built-in types do not allow extra attributes (nor should 
they.)  So, for example, declarePrivate('some_string_attribute') has no 
effect, nor did it ever have any effect.

It's a nasty situation. :-(  But overhauling the security policy is 
probably too big a change for making Zope 2.6 compatible with Python 2.2.

Ironically, the new docstrings are wrong.  ().__doc__ gives you 
information about how to construct a tuple instead of telling you how to 
use the tuple you've already created.  So we could lobby PythonLabs to 
fix the docstrings, but that wouldn't solve Zope's problem.

> alternatively (I really really hate to suggest this)
> we could add some checks to BaseRequest.traverse()
> such that built-in types are not publishable.
> I hate to suggest it because: 
> 
> 1) traverse is already 266 lines
> long!

Even so, we might have to do something like this.  As another option, I 
wonder how well it would work to refuse to publish anything that has no 
__roles__ attribute... or some variation on that.

> 2) it could sometimes be really handy to have trivial
> publishable attributes that are built-in types, 
> either for inspecting the state of an object via a browser or for 
> RAD development of an app in the REST style 
> (Representational State Transfer - see 
> http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html
> for an intro). I could imagine implementing something like:

Zope 2.6 + Python 2.1 tries to disallow access to simple attributes 
because of the number of things it would let you access that you 
couldn't before.  Yes, it would be useful, but we need Zope 2.6 + Python 
2.2 to act the same as Zope 2.6 + Python 2.1.

> Admittedly this is a pretty small difference, and a silly example,
> but there's something really appealing about the simplicity of the 
> first example.

You're going to enjoy Zope 3. ;-)

Shane