[Zope] Nasty subtle security bug - Me Too

[Martijn Faassen]

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.

Regards,

Martijn