[Zope] Nasty subtle security bug - Me Too

Martijn Faassen faassen@vet.uu.nl
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
anonymous only.