[PATCH] chroot support

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by e...@pretzelnet.org on 11 Sep 2008 at 3:50

Attachments:

• diff

[GoogleCodeExporter]

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.

Original comment by Graham.Dumpleton@gmail.com on 11 Sep 2008 at 4:17

• Changed title: [PATCH] chroot support

[GoogleCodeExporter]

Started conversation at:

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

Check for comments by others there.

Original comment by Graham.Dumpleton@gmail.com on 11 Sep 2008 at 4:22

[GoogleCodeExporter]

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.";

    ...
  }

Original comment by Graham.Dumpleton@gmail.com on 11 Sep 2008 at 11:06

[GoogleCodeExporter]

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.

Original comment by Graham.Dumpleton@gmail.com on 11 Sep 2008 at 11:29

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 11 Sep 2008 at 11:30

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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" ;->.

Original comment by e...@pretzelnet.org on 12 Sep 2008 at 5:48

[GoogleCodeExporter]

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.

Original comment by Graham.Dumpleton@gmail.com on 12 Sep 2008 at 7:27

[GoogleCodeExporter]

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.

Original comment by Graham.Dumpleton@gmail.com on 12 Sep 2008 at 7:27

[GoogleCodeExporter]

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.

Original comment by Graham.Dumpleton@gmail.com on 12 Sep 2008 at 7:27

[GoogleCodeExporter]

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

Original comment by Graham.Dumpleton@gmail.com on 12 Sep 2008 at 10:41

[GoogleCodeExporter]

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.

Original comment by Graham.Dumpleton@gmail.com on 13 Sep 2008 at 12:09

[GoogleCodeExporter]

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.

Original comment by e...@pretzelnet.org on 13 Sep 2008 at 7:30

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 17 Sep 2008 at 11:05

• Added labels: Milestone-Release3.0

[GoogleCodeExporter]

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

Original comment by Graham.Dumpleton@gmail.com on 17 Sep 2008 at 11:19

[GoogleCodeExporter]

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

Original comment by Graham.Dumpleton@gmail.com on 22 Nov 2009 at 2:55

• Changed state: Fixed