Hitchhiker's Guide to Openbsd

File system mount options: By default in OpenBSD, your /var partition will be mounted with the 
nosuid
and 
nodev
options. If you attempt to use an application within the chroot, you may need 
to change those options. You may need to do that even if you don't use the chroot option, of course. 
●
Name Resolution: httpd(8) inside the chroot(2) will NOT be able to use the system /etc/hosts or /
etc/resolv.conf. Therefore, if you have applications which require name resolution, you will need to 
populate /var/www/etc/hosts and/or /var/www/etc/resolv.conf in the chroot(2) environment. Note 
that some applications expect the resolution of "localhost" to work. 
●
Timezone: httpd(8) inside the chroot(2) will NOT be able to use the system /etc/localtime. If you 
require localtime logging of events, you will need to copy (not link) the corresponding timezone 
from /usr/share/zoneinfo/ under /var/www/etc/localtime. 
In some cases, the application or configuration can be altered to run within the chroot(2). In other cases, 
you will simply have to disable this feature using the 
-u
 option for httpd(8) in 
/etc/rc.conf.local
. 
Example of chroot(2)ing an app: wwwcount
As an example of a process that can be used to chroot an application, we will look at wwwcount, a simple 
web page counter available through 
packages
. While a very effective program, it knows nothing about 
chroot(2)ed Apache, and will not work chroot(2)ed in its default configuration. 
First, we install the 
wwwcount
 package. We configure it and test it, and we find it doesn't seem to work, 
we get an Apache message saying "Internal Server Error". First step is to stop and restart Apache with the 
-u
switch to verify that the problem is the chroot(2)ing, and not the system configuration. 
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd -u
After doing this, we see the counter works properly, at least after we change the ownership on a directory 
so that Apache (and the CGIs it runs) can write to the files it keeps. So, we definitely have a chroot 
problem, so we stop and restart Apache again, using the default chrooting: 
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd
A good starting point would be to assume wwwcount uses some libraries and other files it can't get to in 
the chroot. We can use the 
ldd(1)
command to find out the dynamic object dependencies that the CGI 
needs: 
# cd /var/www/cgi-bin/
# ldd Count.cgi
http://www.openbsd.org/faq/faq10.html (23 of 32)9/4/2011 10:02:15 AM

---

10 - System Management
Count.cgi:
Start End Type Open Ref GrpRef Name
1c000000 3c007000 exe 1 0 0 /var/www/cgi-
bin/Count.cgi
0c085000 2c0be000 rlib 0 1 0 /usr/lib/libc.
so.57.0
08713000 08713000 rtld 0 1 0 /usr/libexec/
ld.so
Ok, here is a problem, two files that are not available in the chroot(2) environment. So, we copy them 
over: 
# mkdir -p /var/www/usr/lib /var/www/usr/libexec
# cp /usr/lib/libc.so.57.0 /var/www/usr/lib
# cp /usr/libexec/ld.so /var/www/usr/libexec
and try the counter again. 
Well, now the program is running at least, and giving us error messages directly: "Unable to open config 
file for reading". Progress, but not done yet. The configuration file is normally in 
/var/www/
wwwcount/conf
, but within the chroot environment, that would seem to be 
/wwwcount/conf
. Our 
options are to either recompile the program to make it work where the files are now, or move the data 
files. As we installed from a package, we'll just move the data file. In order to use the same config either 
chroot(2)ed or not, we'll use a symbolic link: 
# mkdir -p /var/www/var/www
# cd /var/www/var/www
# ln -s ../../wwwcount wwwcount
Note that the symbolic link is crafted to work within the chroot. Again, we test... and we find we have yet 
another issue. Now wwwcount is complaining that it can't find the "strip image" files it uses to display 
messages. After a bit of searching, we find those are stored in 
/usr/local/lib/wwwcount
, so we 
have to copy those into the chroot, as well. 
# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
we test again... and it works! 
Note that we have copied over only files that are absolutely required for operation. In general, only the 
minimum files needed to run an application should be copied into the chroot.