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. All of these access.log files are defined via a
"CustomLog <path> combined" directive inside of their corresponding
<VirtualHost> directive, and I've disabled the global CustomLog (all my
VirtualHosts have their own anyway). e.g.,
<VirtualHost *:80>
...
ErrorLog /var/log/testapp/error.log
CustomLog /var/log/testapp/access.log combined
...
</VirtualHost>
I have the following modules enabled: alias, authz_host, mime, ssl, wsgi
--
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.
