The short of it is that mod_wsgi was never intended to be used for mass virtual hosting, certainly not of disparate untrusted user code. Its focus is for self managed systems or managed services for disparate users where the user doesn't get the choice to provide their own code.
Despite that, some are still using it for mass virtual hosting. Luckily most at least use daemon mode and run each group as a separate user, although have heard of some not running each group as different user, or using embedded mode for hosting disparate users code, which isn't much better than using mod_python and is a disaster waiting to happen as easily compromised given that all code runs as same user. FWIW, you are the first person who has even looked closely enough to realize that in older mod_wsgi versions error logs were inherited and that access logs still are. This to a degree shows how little effort most people go to to verify the system they are using when using it in a mass virtual hosting type arrangement. Graham On Thursday, September 16, 2010, Sameer Sundresh <[email protected]> wrote: > On Wed, Sep 15, 2010 at 11:55 PM, Graham Dumpleton > <[email protected]> wrote: > > On 16 September 2010 16:50, Sameer Sundresh <[email protected]> wrote: >> On Wed, Sep 15, 2010 at 11:23 PM, Graham Dumpleton >> <[email protected]> wrote: >>> >>> BTW, how paranoid are you wanting to be? There are some options to >>> WSGIDaemonProcess which I seem to have never documented, even in >>> changes file. Nor do I have appeared to mention them on mailing list. >>> >>> These are 'script-user' and 'script-group'. They can be used to >>> enforce, in similar way to suexec, things about the ownership of the >>> WSGI script file, the file owner/group permissions and directory >>> owner/group permissions. >>> >>> I'll have to actually go and refresh myself what they do? >>> >>> If you are being especially paranoid, they may be of interest. >> >> The more paranoid the better ;) >> But realistically, accidentally running a WSGI script that's owned by the >> wrong user isn't something I anticipate running into. The Python code is >> all stored read-only, I just want to minimize how different applications may >> be able to interfere with each other. >> Also, some results with mod_wsgi 3.3: >> Good news: Other applications' error.log files are no longer open in a WSGI >> process (they were with mod_wsg 2.6). >> Bad news: However, all other applications' access.log files are still open >> in all the WSGI processes. > > Sorry, should have said that access logs for all hosts still open, not > just main log. Forgot about that. > > This comes down to being a limitation in Apache in being able to get a > handle for the access log file. > > The only way I know of getting around this is to not use CustomLog at > all. Instead, put a nginx front end in place and have it do access > logging for hosts. > > This has other benefits anyway. These including: > > 1. Saves Apache doing access logging, with Apache likely being slower > at doing it than nginx anyway. > > 2. You get benefits of nginx isolating Apache from slow clients, > allowing Apache to perform better with less resources. > > 3. You can use nginx to serve static files, which it does better than Apache. > > Thanks, that now answers my questions about mod_wsgi. I had a suspicion that > we'd have to switch over to something like nginx, but I wanted to get as much > mileage as I could out of the current setup. I hadn't specifically > considered keeping apache as the layer behind nginx. I'll look into that and > perhaps separate apache instances. I appreciate the advice! > > > > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
