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

[Chris Withers]

Shane Hathaway wrote:
> Chris Withers wrote:
> 
>> 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. :-)

How so? The idea I was suggesting should let you hot-replace the bits that you 
would otherwise have to put into the core...

>>> 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().

Well, you wouldn't use find_module, just load_module. And I'm counting on that 
not to do anything with heirarchical names so that we don't import anything 
we're not planning on importing...

>> 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)

How about just raise a HideousSecurityHole exception? ;-)

>   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.  

They'll be ImportErrors, and I'll be doing an assertRaises.

> Look at whether "failed test" flag gets set.  If it gets set, 
> possibly unauthorized code has already been executed.

...and assertRaises won't catch HideousSecurityHole's. Sound like a plan?

>> 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.

*grumble*

Chris