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

[Shane Hathaway]

Chris Withers wrote:
> Shane Hathaway wrote:
> 
>>
>> The TransparentFolders product requires users to overwrite one of the
>> modules in the Zope source.
> 
> 
> You might be able to use the stuff that PlugginIndexes use to get 
> imported first to make sure you hot-swap the required module before 
> other stuff needs it, so removing the need to actually replce the module 
> on disk.

Interesting idea, but I would have to integrate a piece of 
TransparentFolders into the core, which I wouldn't feel good about.  I 
have to set an example, you know. :-)

>> That said, here's a variation on one of the ideas you proposed that might
>> work out just right: if the requested module is not yet in sys.modules,
>> scan sys.path for a file called <module>/zope_security.py[co].  Don't
>> import anything yet, just look for the file.  If the file is found, 
>> *then*
>> you can import it, and it will make the declarations.
> 
> 
> Did you see my followup in the collector? I prefer that idea but yours 
> may be just as simple to implement...

imp.find_module() doesn't seem to do enough: it can't deal with 
hierarchical names until you load_module().

>> I look forward to it.  I think you can get this right--I've needed 
>> this functionality myself before.  But please be careful, work on a 
>> branch, and write unit tests that verify modules don't accidentally 
>> get imported in order to check declarations.
> 
> 
> Hmmm... how, and more importantly, where should I write these unit tests?

In AccessControl/tests.  I'd create a structure like this:

AccessControl/tests/
   safe_pkg/
     __init__.py
     zope_security.py
   unsafe_pkg/
     __init__.py   (upon import, set a flag that says the test failed)
   safe_module.py
   safe_module_zope_security.py
   unsafe_module.py  (set the failed test flag here too)

Then call guarded_import for safe_pkg, unsafe_pkg, safe_module, and 
unsafe_module.  In the "unsafe" tests, catch and ignore Unauthorized 
errors.  Look at whether "failed test" flag gets set.  If it gets set, 
possibly unauthorized code has already been executed.

>>> 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...
>>
>>
>> It's not an edge case, it's one of Zope's most valuable assets.  We've
>> been using it at ZC extensively lately.
> 
> 
> Really? That's changed recently then. BTW, I don't count customers as 
> 'semi-trusted users'. They are fully trusted users, especially if they 
> choose to get involved in writing code ;-)

It depends on the size of the company/organization.  The larger the 
organization, the more important fine-grained security becomes.  Lots of 
people write templates, and templates contain code, but that does not 
mean they should be able to access any part of a database containing 
millions of objects.

Shane