Add chroot option to WSGIDaemonProcess directive, which causes the daemon children to chroot to the specified directory. This allows applications to be isolated even further from each other, and from the rest of the system.

It's trivial to backport to 2.x, where I'm using it.

Can you provide a quick example including Apache configuration bits for mod_wsgi that uses the option and description of minimum that needs to be setup in chroot environment to have Python still work. I presume it just means making Python installation appear at same location.

Anyway, think I understand what would be required and certainly is an interesting idea, but just want to make sure I understand any gotchas.

I'll post reference to this on mailing list as sure this might be interesting idea for others as well.

Started conversation at:

http://groups.google.com/group/modwsgi/browse_frm/thread/ca6b414e8bdb0f94?hl=en

Check for comments by others there.

The chroot option should not be allowed if at point configuration is parsed the Apache process is not running as root. Ie.,

else if (!strcmp(option, "chroot")) { if (geteuid()) return "Cannot use chroot when Apache not run as root.";

...

}

For the purpose of experimentation, have implemented this chroot feature. The option name is called 'root' though and not 'chroot'. For example:

WSGIDaemonProcess choot-1 user=grahamd group=staff display-name=%{GROUP} \ root=/usr/local/wsgi/restricted-environments/chroot-1

The change is committed at revision 1068 of mod_wsgi trunk.

Whether this feature is kept will depend on being able to provide documentation on how to use it successfully. If a simple process can be provided for setting up required chroot environment with Python and the application in it, then okay. If not, then probably not much point in providing it.

Change has been tested for simple hello world application which doesn't import any additional modules.

Thanks for considering the patch :)

I'm not sure how "root" is better. It can mean many things, and I'd have to check the documentation to see what. "chroot" is immediately obvious. shrug

I hope the feature (a mere 18 lines!) isn't rejected just because it's not simple to document how to setup a chroot environment. That is a complex issue, and I'm not sure how an application such as mod_wsgi could possibly document it. How to go about it is completely system-dependent. Not just when comparing, say NetBSD vs. "Linux", but just compare Debian and Red Hat! With Debian, it's easy with debootstrap. I don't know what tools are available for Red Hat. Of course, you can also write your own custom automation.

In other words, I think all you're looking for is "setting up a chroot environment is beyond the scope of this document" ;->.

The name of the option can be changed, at the time, 'root' called out to me in some ascetic way. :-)

As to documentation, If I don't provide some sort of explanation to at least get people started, then am likely to continually get questions about it on mailing list. I know from the past how that can quite easily sap all my time. Thus am cautious at getting myself into that situation.

The name of the option can be changed, at the time, 'root' called out to me in some ascetic way. :-)

As to documentation, If I don't provide some sort of explanation to at least get people started, then am likely to continually get questions about it on mailing list. I know from the past how that can quite easily sap all my time. Thus am cautious at getting myself into that situation.

The name of the option can be changed, at the time, 'root' called out to me in some ascetic way. :-)

As to documentation, If I don't provide some sort of explanation to at least get people started, then am likely to continually get questions about it on mailing list. I know from the past how that can quite easily sap all my time. Thus am cautious at getting myself into that situation.

Option now 'chroot' as per original patch. Committed in revision 1069.

At revision 1070 checked in changes which mean that configuration enabling WSGI application must reference WSGI script directly where it is located chroot environment. That is, if:

WSGIDaemonProcess chroot chroot=/usr/local/jail

Then have to be:

WSGIScriptAlias / /usr/local/jail/some/path/app.wsgi process_group=chroot

The mod_wsgi daemon process will strip the leading part of the path corresponding to chroot directory automatically so everything works.

This is being forced so as to eliminate/discourage trying to set up parallel directory outside of chroot directory containing symlinks into chroot environment, so as to avoid mistakes which would cause mod_wsgi to fail.

The DOCUMENT_ROOT and SCRIPT_FILENAME variables in WSGI environment are also adjusted to strip chroot directory from front. Note that if DOCUMENT_ROOT is outside of chroot directory, then that variable is simply removed from WSGI environment.

At first I didn't like r1070, but then I thought about it, and agree that it's better. I've switched my 2.3 backport over to this. Thanks.

For example of creating chroot environment for purposes of constructing Python web application in isolated environment see:

http://transcyberia.info/archives/12-chroot-plone-buildouts.html

Version 3.0 of mod_wsgi now released with this major new feature.