Thread: [SQLObject] SQLObject vs mod_python security issue
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: David M. <da...@re...> - 2004-02-28 02:15:11
|
Hi, I've just noticed that SQLObject keeps some sort of process-global 'registry' of tables. This creates a security situation with mod_python. At present, I'm using SQLObject within mod_python on my own server. No problem here, because I can either just: 1) create my tables once within my mod_python handler, or 2) create the tables upon each hit, trapping the resulting exceptions on the second/subsequent hits. However, I'm looking to possibly move one or more sites to a shared vhost server. In this scenario, with SQLObject table classes sitting in a process-global registry, other users on the same server could get access to my tables, which is not completely ideal. Is there any way to stop SQLObject from keeping this registry? Or, should I only host mod_python/SQLObject-using websites on hosts that have separate users running within separate Apache processes? -- Kind regards David -- leave this line intact so your email gets through my junk mail filter |
From: Michael W. <mw...@mi...> - 2004-02-28 02:35:29
|
On Sat, 2004-02-28 at 07:04, David McNab wrote: > I've just noticed that SQLObject keeps some sort of process-global > 'registry' of tables. > > This creates a security situation with mod_python. Interesting. I've never used mod_python and it never occured to me to think about this. Thanks for the heads up. BTW I use Quixote and that project's "SCGI" to avoid one-shot CGI. SCGI uses mod_scgi to simply pass http requests off to the long-running scgi process (which is a Publisher subclass which your application creates) for the application. There certainly is no shared space between individual applications or users - so might be handy in a vhosts situation. I run my own web servers and have client implementations each running their python applications with no concerns. And it performs very well too. But then I happen to like the Quixote model, ymmv... -- Mike Watkins mw...@mi... Absence makes the heart go wander. |
From: David M. <da...@re...> - 2004-02-28 03:00:03
|
Michael Watkins wrote: > BTW I use Quixote and that project's "SCGI" to avoid one-shot CGI. SCGI > uses mod_scgi to simply pass http requests off to the long-running scgi > process (which is a Publisher subclass which your application creates) > for the application. There certainly is no shared space between > individual applications or users - so might be handy in a vhosts > situation. Except that less than 2% of vhosts allow persistent processes. (Not many allow mod_python either, but I'd suspect that there's more vhosts allowing mod_python than persistent processes). David |
From: Michael W. <mw...@mi...> - 2004-02-28 03:29:46
|
On Sat, 2004-02-28 at 07:49, David McNab wrote: > Except that less than 2% of vhosts allow persistent processes. > > (Not many allow mod_python either, but I'd suspect that there's more > vhosts allowing mod_python than persistent processes). Yup, that is indeed an issue. I ended up building out my own rack mounted servers and shipped them off to a co-location centre. Obviously not practical for some... Its probably worth checking into what vhost'ers will and will not do these days. Perhaps they are looking for business with more vigor than in the hey day of 1999/2000 ;-) Also I suspect you would find a friendly ear at any site that supports Zope, since its running a persistent process - and there are quite a few Zope hosters out there these days. SCGI/Quixote with Apache is far, far, lighter load on a server than Zope. Even if you write an application badly (I'm guilty of that I am sure)! In support of SCGI, a typical application starts up only a couple SCGI processes - doesn't matter if you have 10 or 50 apache processes, unless your application is extremely heavily used, those two SCGI processes will keep up just fine. So the load potentially might be lighter (resource wise at lease) than some Apache/mod_python configurations. Mike |
From: Bob I. <bo...@re...> - 2004-02-28 04:12:46
|
On Feb 27, 2004, at 9:49 PM, David McNab wrote: > Michael Watkins wrote: >> BTW I use Quixote and that project's "SCGI" to avoid one-shot CGI. >> SCGI >> uses mod_scgi to simply pass http requests off to the long-running >> scgi >> process (which is a Publisher subclass which your application creates) >> for the application. There certainly is no shared space between >> individual applications or users - so might be handy in a vhosts >> situation. > > Except that less than 2% of vhosts allow persistent processes. > > (Not many allow mod_python either, but I'd suspect that there's more > vhosts allowing mod_python than persistent processes). mod_python is just simply not appropriate for those kinds of vhost environments. I certainly wouldn't put anything I care about in a shared python interpreter with people I don't trust, nor would I use an ISP that was foolish enough to offer that without the option of persistent processes. I do understand that some people can't afford decent hosting for whatever reason, and they should just learn PHP ;) Besides, I bet persistent processes have better performance and scalability.. most requests probably aren't hitting mod_python, so you're eating up more memory than you need.. and if they are mostly hitting python scripts, then what the heck are you using apache for in the first place? It (apache+mod_python) doesn't make anything easier or more reliable. -bob |
From: Luke O. <lu...@me...> - 2004-02-28 08:41:08
|
> In this scenario, with SQLObject table classes sitting in a > process-global registry, other users on the same server could get access > to my tables, which is not completely ideal. To agree with others posting on this issue, I don't see this as an SQLObject issue, but rather the basic inappropriateness of a shared mod_python hosting environment in general. Any environment in which you are sharing an instance of the python interpreter with untrusted parties is simply not going to be secure. A module-level registry makes this apparent, but getting rid of global stores does not change the openness of a python interpreter instance. The rexec/Bastion issues immediately spring to mind as an illustration. - Luke |
From: Ian B. <ia...@co...> - 2004-02-28 18:36:25
|
On Feb 27, 2004, at 8:04 PM, David McNab wrote: > In this scenario, with SQLObject table classes sitting in a > process-global registry, other users on the same server could get > access to my tables, which is not completely ideal. Like other people said, I don't think you can get safety with mod_python in this situation. And I don't think mod_python is much (if any) more common in vhosts than other Python environments. > Is there any way to stop SQLObject from keeping this registry? No, it's pretty essential -- the registry is how SQLObject finds other classes by name (for joins and foreign keys). But if you are just worried about name conflicts, not malicious access, you can define a separate registry for your application by adding a _registry class variable to your classes (a string which identifies your application). -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |