[Zope] Nasty subtle security bug - Me Too
Martijn Faassen
faassen@vet.uu.nl
Mon, 25 Sep 2000 22:13:19 +0200
Martijn Faassen wrote:
[snip]
> In fact I misreported that moving the external method to a subfolder
> solved all problems -- it still fails (at least in 2.2.2, perhaps it worked
> in 2.1.6), as long as the local role needed to execute it is added to the
> user in a subfolder below it). If the role is added in the same folder or
> a folder above the definition of the external method, it works.
More clearing up of misreporting:
The manager role is not special. If a manager role is added as a
local role below the place of definition of the external method or
ZClass instance, that manager will not be able to execute said
objects. (problem also occurs with ZClass instances)
The behavior seems to be more consistent than I originally thought;
it's indepedent of the root folder and the type of role. The main
inconsistency is that it isn't behaving as I'd expect, and that DTML methods
*do* behave as I expect.
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.
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.
Regards,
Martijn