[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/AccessControl
- ZopeGuards.py:1.13
Ken Manheimer
klm@zope.com
Tue, 17 Dec 2002 16:18:47 -0500 (EST)
I hope i'm not going off half-cocked, but this argument does not sound
good.
On Tue, 17 Dec 2002, Chris Withers wrote:
> Shane Hathaway wrote:
>
> <snip examples>
> > There needs to be something that declares that a module is allowed to be
> > imported, otherwise Zope opens up large unknowns.
>
> Well indeed. BUT, how is a module supposed to say it's allowed to be imported?
> Answer: it makes security declarations.
>
> 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).
So you can put something in your product to enable import of modules
not part of your product.
> What does Zope do if it fails to find the declaration?
> Answer: fail to import the module.
More like, "refuse to import the module". There **must** be some way
to prevent import of modules, and it must be a deliberate-allow
policy, rather than deliberate-deny.
It's very appealing to skimp on security until you're the one that's
burned. However, we're *all* burned if we compromise on zope
security. I haven't been following this issue in complete detail, but
it sounds like you're advocating a fix that compromises security for
the sake of convenience, particularly if using ModuleSecurityInfo
serves as i suggest. Even if it's not just convenience, and a feature
is blocked, that's no excuse to compromise security.
--
Ken
klm@zope.com