Re: [Zope] Nasty subtle security bug - Me Too
On Tue, 26 Sep 2000, Martijn Faassen wrote: > 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). Let's say I'm user Joe and I have a role "Employee" that allows me certain functions throughout the site. A role "DepartmentManager" is also available, but I only have that role where it is given to me as a local role in the "accounting" folder. Let's say there's another folder on the site called "hr", for human resources. If security were context-dependent rather than containment-dependent then I could just access http://www.somesite.com/intranet/accounting/intranet/hr/manage and I'd have "DepartmentManager" privileges in the "hr" folder. Oops! (Note that there is only one "intranet" folder. This URL uses acquisition trickery.) (More info in my reply to your next message...) > 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. Tell us what kind of security you're trying to set up, and we can probably help you find the right way to do it. Shane ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Nasty subtle security bug - Me Too
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 ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Nasty subtle security bug - Me Too
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. You probably don't really want to change it to use context instead. It would open a mile-wide security hole. > 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. Shane ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Nasty subtle security bug - Me Too
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 ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Nasty subtle security bug - Me Too
Brad Clements wrote: > On 25 Sep 2000, at 21:01, Martijn Faassen wrote: > > > In Zope 2.2.2, the user cannot execute the external method E either. > > Instead, the calling DTML code raises a NameError, basically saying our > > external method does not exist. > > > I'll also dump this description into the collector, but posted to the > > list because I like to complain. And who knows, perhaps someone else > > ran into the same. > > I also get the same problem in a different way. I posted a note the other > day about Login Manager and ownership generating NameError. > > I thought it was a Login Manager thing. The results are about the same, > I get a NameError accessing an External method from a DTML method > when the current user has been authenticated using a Login manager > protectec sub folder of the root. This was just plain vanilla user folder. I also get it with ZClass instances, though I get a reauthentication request (impossible one) in that case. In 2.1.6, I'd get reauthentication requests for both external methods and ZClass instances. > My fix, strangely enough, was to change the ownershipp of the DTML > method that was making the call to the External Method. It was owned > (somehow) by a user from Login Manager, rather than from the root > acl_users folder. > > Changing the ownership fixed the problem. I don't see how to accomplish this in my page. The root folder isn't owned by anyone, and I can't change it to be owned, I think. The external methods are all owned by my manager user, can I can't seem to change that either. > I didn't know who should look into this, Ty or DC, so I posted to the list. > Unfortunately it looks like no one has responded. I don't have the brains > to figure it out. If it is indeed the same problem, it seems to be a Zope core bug. 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. Regards, Martijn ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Nasty subtle security bug - Me Too
On 25 Sep 2000, at 21:01, Martijn Faassen wrote: > In Zope 2.2.2, the user cannot execute the external method E either. > Instead, the calling DTML code raises a NameError, basically saying our > external method does not exist. > I'll also dump this description into the collector, but posted to the > list because I like to complain. And who knows, perhaps someone else > ran into the same. I also get the same problem in a different way. I posted a note the other day about Login Manager and ownership generating NameError. I thought it was a Login Manager thing. The results are about the same, I get a NameError accessing an External method from a DTML method when the current user has been authenticated using a Login manager protectec sub folder of the root. My fix, strangely enough, was to change the ownershipp of the DTML method that was making the call to the External Method. It was owned (somehow) by a user from Login Manager, rather than from the root acl_users folder. Changing the ownership fixed the problem. I didn't know who should look into this, Ty or DC, so I posted to the list. Unfortunately it looks like no one has responded. I don't have the brains to figure it out. Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
