On Mon, Sep 27, 2010 at 4:28 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > On Sep 26, 2:16 pm, Florian Apolloner <f.apollo...@gmail.com> wrote: >> I am aware of those; but let's imagine a 3rd party library which has >> no idea what a request is. In my logs I still want to know the request >> (even if it's just for formatting purposes…); so I am looking for a >> way to attach request specific info to __all__ logging calls done in >> one request __without__ adding it to the logging call. > > You might be interested in this blog post: > > http://plumberjack.blogspot.com/2010/09/configuring-logging-for-web.html > > which solves the problem you mention (attaching request-specific info, > to all logging calls in a request, including calls made in 3rd party > libraries you use, without having to add "extra" to logging calls). > > However, it requires thread-locals, which for some reason the Django > core team seem to be against: > > http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser > > You might regard the rest of this post OT, but ... I haven't seen any > detailed evidence for the "huge threat" mentioned in that Wiki page. > In fact, Graham Dumpleton, author of mod-wsgi, in this post, seems to > be saying that it's not such a security threat that you need to rule > out use of thread-locals: > > http://groups.google.com/group/django-users/msg/eb686bf30a7e4c26 > > To me, Graham seems right on the money. Of course, if the core team > (or any one else) can point to any known exploits which take advantage > of flaws in Python's thread-locals implementation, that would settle > things right away :-) Even then, the answer would be to fix the hole > in Python.
Is there a known exploit inherent in the use of threadlocals? No. Django's position is entirely defensive. The potential for security issues associated with threadlocals is entirely a function of how they are used. Threadlocals are a vector by which it is possible, either intentionally or accidentally, to allow data to leak from one request to another. This is the starting point of an exploit. Since avoiding this exploit requires you to actively look for potential ways that your threadlocal usage can be abused, Django has made an architectural decision to discourage their use. On top of that, there is the purely architectural argument: threadlocals are a global variable by any other name. They increase coupling in the systems in which they are used. If an engineer came to you and proposed a design that relied upon the use of global variables, they would be soundly ridiculed; but for some reason, calling that same global variable a "threadlocal" makes it socially acceptable. It is entirely possible to build a robust, testable web system without the use of threadlocals. You just need to be thorough in your design work. > Also - even if Django itself doesn't use thread-locals, can you be > sure that any third-party library you are using doesn't do so under > the covers? Truth be told, Django *does* use threadlocals in a couple of very specific circumstances. These uses have been extensively audited to make sure there is no exploit hidden in them. It is possible to use threadlocals in a safe way. If people want to pursue these architectural options, they are free to do so -- there is nothing in Django actively hobbling the use of threadlocals. It's just not a practice that we (as a project) are going to recommend. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
