RE: Leaking HTTP requests (was: RE: [Zope] LeakingAcquisition.Imp licitAcquirerWrapper)
Chris, Thanks for the insight. I'm quite sure I don't have any folders with such security settings however. I was looking for a security audit script of some kind but the only I found didn't seem to work :( But if I understand correctly, the leak would come from the raising of an error by SimpleItem.raise_standardErrorMessage, which could be anything really, not just security related? If so, I should maybe be able to detect a pattern between things appearing in the error_log and the incrementing of refcounts for HTTP request related classes. This idea sounds like it may have potential for me now that you mention it actually, I'm going to go look at that right now! I'll see what happens to my site when I remove standard_error_message as well, to see if that's a viable option ... Thanks again for all the insights! J.F. -----Original Message----- From: Chris McDonough [mailto:chrism@plope.com] Sent: May 13, 2004 5:50 PM To: Brian Lloyd Cc: Stefan H. Holek; Jean-Francois.Doyon@CCRS.NRCan.gc.ca; zope@zope.org Subject: RE: Leaking HTTP requests (was: RE: [Zope] LeakingAcquisition.ImplicitAcquirerWrapper) Tres and me were playing around with this a little and the easiest way to provoke a REQUEST leak is to do an anonymous request to a resource inside a subfolder where the subfolder has all permission acquisition turned off (and only "authenticated" granted view access). It will turn around and try to run "standard_error_message", which will fail due to security (and leak in the process). The code responsible for this is SimpleItem.raise_standardErrorMessage, which does some funky passing around/munging of traceback objects. However, "raise_standardErrorMessage" never gets called if "standard_error_message" doesn't exist in the acquisition path. If it never gets called, the leak does not occur. The simplest way to rid yourself of the leak temporarily is to remove "standard_error_message". On Thu, 2004-05-13 at 17:41, Brian Lloyd wrote:
Zope.org doesn't use Localizer (or Archetypes - another thing that has come up in this thread).
In our experience, this sort of thing has almost always turned out to be a wrapped object ending up in the REQUEST or a wrapped object holding onto a request for some reason.
I've attached a quick product you can drop in to test that theory on your own instance (just make a directory Products/LeakBGone and drop this __init__.py into it and restart).
If it fixes the leak, we can extend it to do some logging and try to figure out the root cause. I'll try it out on zope.org as soon as I'm able.
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: zope-bounces+brian=zope.com@zope.org [mailto:zope-bounces+brian=zope.com@zope.org]On Behalf Of Stefan H. Holek Sent: Thursday, May 13, 2004 3:14 PM To: Brian Lloyd Cc: Jean-Francois.Doyon@CCRS.NRCan.gc.ca; zope@zope.org Subject: Re: Leaking HTTP requests (was: RE: [Zope] LeakingAcquisition.ImplicitAcquirerWrapper)
Does zope.org use Localizer or some type of "global request" patch?
Stefan
On Donnerstag, Mai 13, 2004, at 21:42 Europe/Vienna, Brian Lloyd wrote:
FWIW - zope.org is suffering hugely from this as well, so I'm following this thread eagerly ;) -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
______________________________________________________________________ _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
participants (1)
-
Jean-Francois.Doyon@CCRS.NRCan.gc.ca