2009/12/12 amvtek <[email protected]>:
> Hi,
> I am tinkering with mod_wsgi trying to adress some project
> requirements we have.
>
> One issue we are facing can be summarized as follow :
> * At startup, a wsgi application needs to read some sensitive data
> out of the file system .
> * Ideally, to match security best practice the file to be parsed
> would be readable by root only.
> * This would require having the processes which will host the wsgi
> application, to start as root, read the private file, and then change
> user and chroot.
>
> I am seing that WSGIDaemonProcess allow setting a custom user, group
> and root , but I am unsure that this is sufficient to fullfill the
> above requirement. Any idea on how mod_wsgi could be a match for what
> is briefly described.
The simple answer is that mod_wsgi as is or by itself cannot be used
as it doesn't provide feature for user running code in Apache parent
process prior to child processes being forked and root privileges
being dropped.
A better designed solution to achieve that would mean writing your own
custom Apache C module which all it does is read the configuration on
module initialisation in Apache parent process and holds it in memory.
You would then write a separate Python C extension module to allow you
to access those in memory data structures.
There is also a really hacky solution. It would though only work in
mod_wsgi 2.X, unless in mod_wsgi 3.X you turn off the new lazy
initialisation feature for Python and restore it to 2.X way of doing
things, which was to initialise Python interpreter in Apache parent
process. As this interpreter initialisation occurs as root, you could
fudge up a .pth file in site-package directory which does an import of
module/code which reads the configuration file. That would be held in
Python object memory and could then be accessed in application code
later after privileges dropped.
To use this hack you would need to set:
WSGIApplicationGroup %{GLOBAL}
to force your web application to run in main Python interpreter, as
that is the only one which is initialised in Apache parent as root.
You ideally wouldn't run any other web applications on server unless
you can work out way of knowing in main interpreter and only doing
that .pth fiddle for main interpreter if nature of information is
privileged and shouldn't be able to be seen by other web applications
on the server.
Technically this hack could also be used to preload web application
code so long as it didn't do significant initialisation such as
starting up database connections etc. This would help to avoid startup
costs of loading web application code in child process. For some large
frameworks such as TurboGears, such startup costs could be
significant.
That all said, I wouldn't recommend this hack approach as something
your average user would use. In mod_wsgi 3.X, would also mean
reverting back the interpreter intialisation behaviour, which was
changed to avoid issues with Python interpreter leaking memory into
Apache parent on Apache restarts.
Graham
--
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.
