[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/AccessControl - ZopeGuards.py:1.13

[Chris Withers]

Ken Manheimer wrote:
>>How does Zope find these declarations?
>>Answer: by importing the module.
> 
> That's not the whole story.  A module need not make its own security
> declarations - other modules can do so (using eg ModuleSecurityInfo).

Yeah, but if you're distributing a package (stripogram in this case), it's very 
difficult to help people to make it work. Explaining that they either have to go 
and 'hack their Zope source' by twiddling in Products/PythonScripts/standard.py 
_or_ put the package in Products but then make sure they change all their import 
statements to start with 'Products.' _or_ write a pseudo product that does 
nothing but make the security assertions for the package (which they'd have to 
copy from the package source somewhere) just so they can use a package from 
Script(Python)'s all seems like a bit of a nightmare and often ends up with 
complaints of "you said it would work, but it didn't!"

> So you can put something in your product to enable import of modules
> not part of your product.

It's not a product, it's just a python package, this is the problem ;-)

> More like, "refuse to import the module".

Yeah, so it can never find any security assertions made in that module!

> There **must** be some way
> to prevent import of modules, and it must be a deliberate-allow
> policy, rather than deliberate-deny.

Agreed. Evan has made some good suggestions in the collector, which I'm going to 
implement today.

> serves as i suggest.  Even if it's not just convenience, and a feature
> is blocked, that's no excuse to compromise security.

I don't believe it does compromise security. We're always bending over backwards 
to cater for the use case where semi-trusted users write code. This is such an 
edge case that I really think we should discuss whether it needs to exist or not 
at some point...

cheers,

Chris

>