Voodoo with ModuleSecurityInfo, was Re: [Zope] importing encode_base64

[Paul Winkler]

On Mon, Jun 06, 2005 at 05:50:42PM -0400, Paul Winkler wrote:
> On Fri, Jun 03, 2005 at 04:58:57PM -0400, Paul Winkler wrote:
> > Just now I saw something that *may* be related,
> > some imports that were fine on zope 2.7.3 are giving me
> > trouble on 2.7.6, but this is a very preliminary observation
> > and i have not had time to troubleshoot yet.  Monday...
> 
> False alarm, I get the same problem in 2.7.3 and 2.7.0,
> most likely an error in my own code.

Maybe the following will be interesting, if not helpful,
at some date in the future if somebody else experiences weird problems 
with ModuleSecurityInfo().declarePublic()...

More info about the symptom:

While importing (i.e. from a .zexp file) an entire CMF site, I was
getting an Unauthorized error that I was not allowed to access the method 
(let's call it 'foo') in the current context.  
Now, foo.py is a script in one of my filesystem directory views, and is 
used both for a keyword index and metadata in my catalog tool.
And yes, I verified that there is no other object by that name.

foo.py is pretty darn simple:
 
from Products.FooProduct import Utils
return Utils.foo(context)


And in Products/FooProduct/__init__.py, I had this:

ModuleSecurityInfo('Products.FooProduct').declarePublic(
    'blah', 'foo')


The interesting thing is that all this works just fine in the
normal operation of the CMF site.  It *only* raises Unauthorized
during an import of a .zexp of the CMF site.

As if that wasn't weird enough, after a very long and tedious round of 
troubleshooting today, I discovered that two changes were sufficient to 
make the symptom go away:

* Remove an (unused) import from FooProduct/__init__.py.
(The imported object was a class, defined in the same Utils.py as the
foo function. This import was vestigial.)

* Completely remove another product (which does not import any code from
FooProduct, nor vice versa.)

Neither of these changes alone is sufficient - I have to do both.
Once I do that, I can import the .zexp, then I can revert those
code changes and restart zope and all is good.
Neither one of those changes has anything whatsoever to do with foo.py
AFAICT.  Sounds bizarre, but this is 100% reproducible.
This is some crazy voodoo. If I can boil it down to a reasonably small
demonstration, I'll file a collector issue. 

But I don't think I will bother to, because it finally occurred to me
that if I change the form of the import in the script, it works.
i.e. if I change foo.py to look like this:

from Products.FooProduct.Utils import foo
return foo(context)

... then it works all the time, even during the import,
regardless of the aforementioned voodoo changes.

Weird, huh?

Security sucks.

-- 

Paul Winkler
http://www.slinkp.com