There is a new version of this tutorial available for Debian 8 (Jessie).

Chrooting Apache2 With mod_chroot On Debian Etch

Version 1.0
Author: Falko Timme

This guide explains how to set up mod_chroot with Apache2 on a Debian Etch system. With mod_chroot, you can run Apache2 in a secure chroot environment and make your server less vulnerable to break-in attempts that try to exploit vulnerabilities in Apache2 or your installed web applications.

I do not issue any guarantee that this will work for you!


1 Preliminary Note

I'm assuming that you have a running Debian Etch system with a working Apache2, e.g. as shown in this tutorial: The Perfect Setup - Debian Etch (Debian 4.0). In addition to that I assume that you have one or more web sites set up within the /var/www directory (e.g. if you use ISPConfig).


2 Installing mod_chroot

To install mod_chroot, we simply run:

apt-get install libapache2-mod-chroot

Then we enable mod_chroot and restart Apache:

a2enmod mod_chroot
/etc/init.d/apache2 force-reload


3 Configuring Apache

I want to use the /var/www directory as the directory containing the chroot jail. Debian's Apache uses the PID file /var/run/; when Apache is chrooted to /var/www, /var/run/ translates to /var/www/var/run/ Therefore we create that directory now:

mkdir -p /var/www/var/run
chown -R root:root /var/www/var/run

Now we must tell Apache that we want to use /var/www as our chroot directory. We open /etc/apache2/apache2.conf, and right below the PidFile line, we add a ChrootDir line:

vi /etc/apache2/apache2.conf

# PidFile: The file in which the server should record its process
# identification number when it starts.
PidFile /var/run/
ChrootDir /var/www

Next we must tell our vhosts that the document root has changed (for example, a DocumentRoot /var/www translates now to DocumentRoot /). We can do this either by changing the DocumentRoot directive of each vhost, or more easier, by creating a symlink in the file system.

3.1 First Method: Changing The DocumentRoot

Let's assume we have a vhost with DocumentRoot /var/www. We must now open the vhost configuration of that vhost and change DocumentRoot /var/www to DocumentRoot /. Accordingly, DocumentRoot /var/www/web1/web would now translate to DocumentRoot /web1/web, and so on. If you want to use this method, you must change the DocumentRoot for every single vhost.


This method is easier, because you have to do it only once and don't have to modify any vhost configuration. We create a symlink pointing from /var/www/var/www to /var/www:

mkdir -p /var/www/var
cd /var/www/var
ln -s ../../ www

Finally, we have to stop Apache, create a symlink from /var/run/ to /var/www/var/run/, and start it again:

/etc/init.d/apache2 stop

ln -s /var/www/var/run/ /var/run/
/etc/init.d/apache2 start

That's it. You can now call your web pages as before, and they should be served without problems, as long as they are static HTML files or using mod_php.

If you are using CGI, e.g. Perl, suPHP, Ruby, etc., then you must copy the interpreter (e.g. /usr/bin/perl, /usr/sbin/suphp, etc.) to the chroot jail together with all libraries needed by the interpreter. You can find out about the required libraries with the ldd command, e.g.

ldd /usr/sbin/suphp

server2:/var/www/web1/log# ldd /usr/sbin/suphp =>  (0xffffe000) => /usr/lib/ (0xb7e34000) => /lib/tls/i686/cmov/ (0xb7e0f000) => /lib/ (0xb7e03000) => /lib/tls/i686/cmov/ (0xb7cd2000)
        /lib/ (0xb7f23000)

If you've copied all required files, but the page still isn't working, you should take a look at the Apache error log. Usually it tells you where the problem is. Also read for known problems and solutions.


Falko Timme

About Falko Timme

Falko Timme is an experienced Linux administrator and founder of Timme Hosting, a leading nginx business hosting company in Germany. He is one of the most active authors on HowtoForge since 2005 and one of the core developers of ISPConfig since 2000. He has also contributed to the O'Reilly book "Linux System Administration".

Share this page:

Suggested articles

5 Comment(s)

Add comment



Actually Chroot was designed as a way of privilege separation which in it self is a security measure, meaning compromise of an application does not compromise the entire system (similar principle with Mandatory access schemes like Selinux)


chroot is for sandboxing build processes. It's not a security tool.

Alain Cox stated that "chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different."



Thanks for great (as always) tutorial. Unfortunately I can't agree with your statement "With mod_chroot, you can run Apache2 in a secure chroot environment [..]". Chroot is not a security tool, you can rely on it in terms of security. It wasn't designed with security purposes in mind, so it's behavior can change without notice ;)



 Doing a symlink inside a jail is not a good idea... but could be an easy way to do.

But my apache told me that

 [Tue Mar 18 18:47:23 2008] [error] [client xxxxx] Symbolic link not allowed or link target not accessible: /web

After few research I found that old discussion

Nevermind, how do you success to make symlink working ?  

By: srn

Hi all,


If one compromises your apache installation an runs an exploit which gives him root access,

can he access the real filesystem?