ZCatalog madness. (Must log in as emergencyuser.)
Right. This is the traceback I get, after doing a search (searchResults) - which goes fine by teh way - and then trying to do an getobject(x.data_record_id_) as a non-emergencyuser user get up an login box and press escape: Unauthorized Sorry, a Zope error occurred. Traceback (innermost last): File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/OFS/DTMLMethod.py, line 189, in __call__ (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_String.py, line 538, in __call__ (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_In.py, line 702, in renderwob (Object: candidateEngine(REQUEST)) Unauthorized: 0 Right. Your average unauthorized I should think. Next, if I log in as the emergencyuser, this is what I get: Traceback (innermost last): File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/OFS/DTMLMethod.py, line 189, in __call__ (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_String.py, line 538, in __call__ (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_In.py, line 711, in renderwob (Object: candidateEngine(REQUEST)) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/OFS/Traversable.py, line 107, in absolute_url (Object: CatalogAware) AttributeError: (see above) Error Type: AttributeError Error Value: 'string' object has no attribute 'get' The get thing is probably from me trying to call absolute_url on the objects it returns. Calling atributes works, though. Strange. Doing getobject as a non-emergencyuser doesn't owrk, and when I have logged in the objects I get seems to be somewhat fubar. Help is greatly appretiated. (PS. I seem to recall a checkin in hte CVS about unrestrictedTraverse in one of the files belonging to the Catalog, could this has something to do with it?) Zope 2.3.1b1 on Linux.
I'm not sure why this isn't in 2.3.1b1, but yes, the code in getobject was changed to use unrestrictedTraverse for this very reason. ----- Original Message ----- From: "Erik Enge" <erik@esol.no> To: <zope-dev@zope.org> Cc: <jens@digicool.com> Sent: Thursday, February 22, 2001 10:33 AM Subject: [Zope-dev] ZCatalog madness. (Must log in as emergencyuser.)
Right.
This is the traceback I get, after doing a search (searchResults) - which goes fine by teh way - and then trying to do an getobject(x.data_record_id_) as a non-emergencyuser user get up an login box and press escape:
Unauthorized
Sorry, a Zope error occurred.
Traceback (innermost last): File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/OFS/DTMLMethod.py, line 189, in __call__ (Object: candidate_search) File
/usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_String.py,
line 538, in __call__ (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_In.py, line 702, in renderwob (Object: candidateEngine(REQUEST)) Unauthorized: 0
Right. Your average unauthorized I should think. Next, if I log in as the emergencyuser, this is what I get:
Traceback (innermost last): File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/OFS/DTMLMethod.py, line 189, in __call__ (Object: candidate_search) File
/usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_String.py,
line 538, in __call__ (Object: candidate_search) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/DocumentTemplate/DT_In.py, line 711, in renderwob (Object: candidateEngine(REQUEST)) File /usr/local/Zope-2.3.1b1-linux2-x86/lib/python/OFS/Traversable.py, line 107, in absolute_url (Object: CatalogAware) AttributeError: (see above)
Error Type: AttributeError Error Value: 'string' object has no attribute 'get'
The get thing is probably from me trying to call absolute_url on the objects it returns. Calling atributes works, though.
Strange. Doing getobject as a non-emergencyuser doesn't owrk, and when I have logged in the objects I get seems to be somewhat fubar.
Help is greatly appretiated.
(PS. I seem to recall a checkin in hte CVS about unrestrictedTraverse in one of the files belonging to the Catalog, could this has something to do with it?)
Zope 2.3.1b1 on Linux.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Chris McDonough wrote:
I'm not sure why this isn't in 2.3.1b1, but yes, the code in getobject was changed to use unrestrictedTraverse for this very reason.
Does that open up a security hole? Can I get to an object via the getobject method of ZCatalog that I can't get to otherwise? I thought that was the reason it was changed to restrictedTraverse in the first place. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
You can get the object, but you can't do anything with it. ----- Original Message ----- From: "Steve Alexander" <steve@cat-box.net> To: "Chris McDonough" <chrism@digicool.com> Cc: "Erik Enge" <erik@esol.no>; <zope-dev@zope.org>; <jens@digicool.com> Sent: Thursday, February 22, 2001 12:38 PM Subject: Re: [Zope-dev] ZCatalog madness. (Must log in as emergencyuser.)
Chris McDonough wrote:
I'm not sure why this isn't in 2.3.1b1, but yes, the code in getobject was changed to use unrestrictedTraverse for this very reason.
Does that open up a security hole?
Can I get to an object via the getobject method of ZCatalog that I can't get to otherwise?
I thought that was the reason it was changed to restrictedTraverse in the first place.
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Thu, 22 Feb 2001, Chris McDonough wrote:
I'm not sure why this isn't in 2.3.1b1, but yes, the code in getobject was changed to use unrestrictedTraverse for this very reason.
On closer inspection, I can see that it is actually changed in 2.3.1b1. It does say unrestrictedTraverse (line 457, I belive). I grepped for restrictedTraverse, but couldn't find any occurances (lib/python/Products/ZCatalog). Why am I still being asked to log in as emergencyuser to be able to do this, if I'm not using restrictedTraverse. And is there a way to actuall give access to restrictedTraverse (or, probably more corretly, to let it traverse)?
No... what are you getobjecting? Does it happen only with certain kinds of objects? Are they ZClass objects or Product-based objects? ----- Original Message ----- From: "Erik Enge" <erik@esol.no> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope-dev@zope.org> Sent: Friday, February 23, 2001 9:23 AM Subject: Re: [Zope-dev] ZCatalog madness. (Must log in as emergencyuser.)
On Thu, 22 Feb 2001, Chris McDonough wrote:
I'm not sure why this isn't in 2.3.1b1, but yes, the code in getobject was changed to use unrestrictedTraverse for this very reason.
On closer inspection, I can see that it is actually changed in 2.3.1b1. It does say unrestrictedTraverse (line 457, I belive). I grepped for restrictedTraverse, but couldn't find any occurances (lib/python/Products/ZCatalog). Why am I still being asked to log in as emergencyuser to be able to do this, if I'm not using restrictedTraverse. And is there a way to actuall give access to restrictedTraverse (or, probably more corretly, to let it traverse)?
On Fri, 23 Feb 2001, Chris McDonough wrote:
No...
"No" to which question?
what are you getobjecting? Does it happen only with certain kinds of objects? Are they ZClass objects or Product-based objects?
It happens with all kinds of objects I have in my index. All my objects in the index are from Python-based products.
"No" to which question?
No to the question "And is there a way to actuall give access to restrictedTraverse (or, probably more corretly, to let it traverse)?"
what are you getobjecting? Does it happen only with certain kinds of objects? Are they ZClass objects or Product-based objects?
It happens with all kinds of objects I have in my index. All my objects in the index are from Python-based products.
Are they all of one type? unrestrictedTraverse uses the security policy code to determine user access to an object, which is at this point (unfortunately) different than the way that publishing traversal security works. Can you replicate the behavior across many different kinds of objects, or is this problem only with a single type of object?
On Fri, 23 Feb 2001, Chris McDonough wrote:
It happens with all kinds of objects I have in my index. All my objects in the index are from Python-based products.
Are they all of one type?
The same type (as in, they are all Python based), but with different meta_types.
Can you replicate the behavior across many different kinds of objects, or is this problem only with a single type of object?
Different kinds of meta_types or ZClass/Python classes?
different python classes. Do they inherit from a common base class? Did you make these objects or are they from another Product or are they standard Zope objects (like DTML methods, etc.)? ----- Original Message ----- From: "Erik Enge" <erik@esol.no> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope-dev@zope.org> Sent: Friday, February 23, 2001 1:55 PM Subject: Re: [Zope-dev] ZCatalog madness. (Must log in as emergencyuser.)
On Fri, 23 Feb 2001, Chris McDonough wrote:
It happens with all kinds of objects I have in my index. All my objects in the index are from Python-based products.
Are they all of one type?
The same type (as in, they are all Python based), but with different meta_types.
Can you replicate the behavior across many different kinds of objects, or is this problem only with a single type of object?
Different kinds of meta_types or ZClass/Python classes?
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Fri, 23 Feb 2001, Chris McDonough wrote:
different python classes. Do they inherit from a common base class?
Yes. A homemade one.
Did you make these objects or are they from another Product or are they standard Zope objects (like DTML methods, etc.)?
It's a mix. Most of them I created (probably around 30-50 classes) and the remaining (5-10) are variants of DTML Method, Image, File and others.
And any access to getobject with any data_record_id_ returns unauthorized for any user besides emergency user? Or is it a specific set of objects? A specific set of users? ----- Original Message ----- From: "Erik Enge" <erik@esol.no> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope-dev@zope.org> Sent: Friday, February 23, 2001 2:01 PM Subject: Re: [Zope-dev] ZCatalog madness. (Must log in as emergencyuser.)
On Fri, 23 Feb 2001, Chris McDonough wrote:
different python classes. Do they inherit from a common base class?
Yes. A homemade one.
Did you make these objects or are they from another Product or are they standard Zope objects (like DTML methods, etc.)?
It's a mix. Most of them I created (probably around 30-50 classes) and the remaining (5-10) are variants of DTML Method, Image, File and others.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Fri, 23 Feb 2001, Chris McDonough wrote:
And any access to getobject with any data_record_id_ returns unauthorized for any user besides emergency user?
Hm... No, not entirely correct. If I don't get any hits, I don't get the unauthorized, but that is probably because I don't even try the getobject. The point I'm making is that I might be able to call getobject with a bogus data_record_id_ (although I highly doubt it). Steve Alexander suggested that I try the ZCatalog from CVS. The problem is fixed there, isn't it?
And any access to getobject with any data_record_id_ returns unauthorized for any user besides emergency user?
Hm... No, not entirely correct. If I don't get any hits, I don't get the unauthorized, but that is probably because I don't even try the getobject. The point I'm making is that I might be able to call getobject with a bogus data_record_id_ (although I highly doubt it).
It wouldn't return unauthorized if you passed it a bogus data_record_id_, it would fail differently. I meant to narrow down the problem domain in cases where you do call getobject... cases where you aren't calling getobject are not relevant. It would be helpful to find out for which objects getobject fails and for which it succeeds under your setup. I suspect that it's a __roles__ problem with a type of object being retrieved. These kind of problems are notoriously difficult to debug. :-(
Steve Alexander suggested that I try the ZCatalog from CVS. The problem is fixed there, isn't it?
You can try it, but I don't think there's any significant difference between the ZCatalog in CVS and the one in Zope 2.3b1 if you see "unrestrictedTraverse" in your 2.3b1's ZCatalog.py's getobject method. Narrowing the problem down to a set of objects for which getobject *always* fails is probably the first step. Then maybe I can reproduce it here if you can give me the code for these objects.
On Fri, 23 Feb 2001, Chris McDonough wrote:
I meant to narrow down the problem domain in cases where you do call getobject... cases where you aren't calling getobject are not relevant.
Ok. I see.
It would be helpful to find out for which objects getobject fails and for which it succeeds under your setup. I suspect that it's a __roles__ problem with a type of object being retrieved.
Interessting...
Narrowing the problem down to a set of objects for which getobject *always* fails is probably the first step. Then maybe I can reproduce it here if you can give me the code for these objects.
I'll see if I don't have the time to do this bright and early in the morning, but - as I've said - I suspect it is true for all kinds of objects and meta_types. Feedback and debug information coming your way as soon as possible :)
On Fri, 23 Feb 2001, Erik Enge wrote:
Feedback and debug information coming your way as soon as possible :)
Ok, I index DTML Methods, Python objects, and all different kind of things. Then I did a search, meta_type set to 'DTML Method' and it gave me an unauthorized. Strangeness. I've installed the latest Hotfix, but that didn't make any difference either.
I can't replicate this behavior with normal objects. :-( ----- Original Message ----- From: "Erik Enge" <erik@esol.no> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope-dev@zope.org> Sent: Saturday, February 24, 2001 4:58 AM Subject: Re: [Zope-dev] ZCatalog madness. (Must log in as emergencyuser.)
On Fri, 23 Feb 2001, Erik Enge wrote:
Feedback and debug information coming your way as soon as possible :)
Ok, I index DTML Methods, Python objects, and all different kind of things. Then I did a search, meta_type set to 'DTML Method' and it gave me an unauthorized. Strangeness.
I've installed the latest Hotfix, but that didn't make any difference either.
On Sat, 24 Feb 2001, Chris McDonough wrote:
I can't replicate this behavior with normal objects. :-(
Riiight... *thinking very hard* I just realized how it all started. Me and a collegue was indexing objects, searching, doing regular development (probably changing classes, attributes etc.) and suddenly we were asked for the (then) SuperUser password. This was under 2.2.5. I remember thinking: "hm. that's odd...". But I had more important things on my mind (and this wasn't really my field of expertice) so I didn't dwell much on it. I'm trying to remember what we did when it happend, but I'm sorry to say I can't (it's been two, three weeks now). But, the good point - I guess - is that it hasn't got anything to do with Zope 2.3.1b1 in perticular. The sad thing, is that the problem is probably due to some of Python classes begin set up correctly, or accordingly to the Product API. That's what I'm guessing anyways. I'll run some more tests to make sure these assumptions are correct. More feedback, and hopefully a solution, to come this week. Sorry for not realizing this sooner, it would've saved us all lots of time.
If you're using getobject to retrieve bog-standard indexed DTML methods, Python Scripts, etc., you should never get an unauthorized from getobject (although you *will* later get an unauthorized if youy try to do anything with that object if you don't have an adequate set of roles). It's only if you're using getobject to retrieve custom instances that it could conceivably happen in getobject itself. Or at least that's what my Zope here tells me. :-) These problems suck. ----- Original Message ----- From: "Erik Enge" <erik@esol.no> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope-dev@zope.org> Sent: Saturday, February 24, 2001 3:18 PM Subject: Re: [Zope-dev] ZCatalog madness. (Must log in as emergencyuser.)
On Sat, 24 Feb 2001, Chris McDonough wrote:
I can't replicate this behavior with normal objects. :-(
Riiight...
*thinking very hard*
I just realized how it all started. Me and a collegue was indexing objects, searching, doing regular development (probably changing classes, attributes etc.) and suddenly we were asked for the (then) SuperUser password. This was under 2.2.5.
I remember thinking: "hm. that's odd...". But I had more important things on my mind (and this wasn't really my field of expertice) so I didn't dwell much on it.
I'm trying to remember what we did when it happend, but I'm sorry to say I can't (it's been two, three weeks now). But, the good point - I guess - is that it hasn't got anything to do with Zope 2.3.1b1 in perticular.
The sad thing, is that the problem is probably due to some of Python classes begin set up correctly, or accordingly to the Product API. That's what I'm guessing anyways.
I'll run some more tests to make sure these assumptions are correct. More feedback, and hopefully a solution, to come this week.
Sorry for not realizing this sooner, it would've saved us all lots of time.
participants (3)
-
Chris McDonough -
Erik Enge -
Steve Alexander