[Zope] Nasty subtle security bug - Me Too
Tue, 26 Sep 2000 19:42:51 +0200
Shane Hathaway wrote:
> Martijn Faassen wrote:
> > General problem description:
> > For a ZClass instance/external methods that is only viewable by
> > users with a particular role, the view operation fails if that role
> > is only added to a user in a place deeper in the folder tree than the
> > folder where the External Method/ZClass instance was defined. This
> > occurs when the 'view' is occuring in the acquisition context of the
> > folder.
> > It succeeds if the role is added to the user in a folder higher in the
> > tree, at or above the folder where the external method or ZClass instance
> > is defined.
> This sounds 100% correct. When checking security, acquisition context
> is ignored. What matters is *containment* (which is also accessed
> through the acquisition machinery, but in a special way: aq_inner). A
> user can only access objects that are defined in a container where the
> user is granted access.
How come it does work with DTML methods then?
I can access a DTML method 'foo' defined in the root folder that is
only accessible with role A, even if role A is only added to me in
a subfolder (from this subfolder).
> You probably don't really want to change it to use context instead. It
> would open a mile-wide security hole.
Depends on how you reason. I was reasoning context based -- I should
be able to execute something in the context of the current folder, if
I have the right role to do it. That's exactly how it works with DTML methods,
so I didn't expect external methods to be different.
If you're opening a mile-wide security hole with external methods, then
why not with DTML methods?
> > The view operation fails with a reauthentication request in Zope 2.1.6
> > (so authentication exception raised presumably).
> > In Zope 2.2.2 the failure is a NameError for External Methods, and
> > reauthentication for ZClass instances.
> > Am I missing something terribly obvious, or is this a rather huge bug
> > that's been unnoticed for a long time? I assume it *must* be a bug as
> > DTML methods behave in a different way. I also want it to be a bug, as
> > I don't like this behavior. It makes it very hard to delegate
> > responsibility.
> The difference is a result of the change in the way security is
> handled. It now gets a NameError because the name lookups skip over
> entries to which you're disallowed access. That logic can be very
> puzzling, but you might try the ZDebug product which helps you make
> sense of it.
Okay, I'll try that.
I still don't see why DTML methods are different. Could you explain that?
That's what initially caused much of my confusion; the DTML methods
behave as expected, but call external methods that *don't*, which have
*exactly* the same security settings.
Note that this policy does make acquisition rather useless for delegating
of responsibility, unless you're either using DTML only, or are coding for