Quick-Fix for using Perl within an OpenBSD Apache Chroot

Original: June 1, 2003
Updated: November 22, 2004

Introduction

There's not enough detail given here, use at your own risk, and all that stuff. Basically, this is a quick-n-dirty way to make Perl CGI scripts work within the Apache Chroot of OpenBSD. There are likely Perl and Apache modules that are copied here which won't be needed in all installs, something to look into if you're working on a large project - but if you're contemplating passing httpd the -u flag to make a Perl CGI work this will likely be the safer route.

If you're trying to get something other than Perl (or Apache modules) working within the chroot, this might give some idea how to start. Some people suggest using ldd to find out which libraries are needed. That probably would be a good start, to generate this list for Perl however I basically wrote a simple test CGI and watched the Apache error_log to see what complaints were generated, and added all the base Perl Modules as well. If this doesn't give enough detail to figure out something specific, another method that works fairly well is to use systrace -A perl <scriptname.cgi> then peruse the resulting file in $HOME/.systrace/var_www_path_to_scriptname.cgi - keep an eye on the attempted file reads. Any that aren't in your chroot may cause problems for your particular application. (Try grepping for native-fsread to find all files accessed, presumably after the steps below most of those will already be within your chroot.)

Note that any additionally installed Perl Modules will need to be copied into the /var/www/usr/local/libdata directory. Also, with OpenBSD 3.4 there were just over 3000 files copied following the steps below, making up less than 40MB. Since /usr and /var should be seperate mount points, and even /var/www on a webserver, there's no discussion of hardlinks =) There's also no discussion of using mount_null to provide for the majority of the files with the least maintenance afterward - it didn't work with OpenBSD 3.3 and I haven't had a chance to try again with 3.4.

The assumptions made are that the Apache Chroot is /var/www, all currently installed Perl and Apache Modules are to be copied, and that paths should mimic the system layout so that CGIs in the chroot specify the same paths they would outside the chroot - this essentially means mapping /usr/dir to /var/www/usr/dir. Also, it should go without saying, you'll need to su - first to have sufficient permissions.

 
cd /var/www
mkdir -p etc usr
cd etc
  cp /etc/resolv.conf .
  cp /etc/services .
  cd ..
cd usr
  mkdir -p bin lib libdata libexec local
  cd bin
    cp /usr/bin/perl .
    cp /usr/bin/perl5.8.0 .
  cd ../lib
    cp -R /usr/lib/apache/ .
    cp /usr/lib/libc.* .
    cp /usr/lib/libm.* .
    cp /usr/lib/libperl* .
    cp /usr/lib/libutil* .
  cd ../libdata
    cp -R /usr/libdata/perl5/ .
  cd ../libexec
    cp /usr/libexec/ld.so .
  cd ../local
    mkdir -p libdata
    cd libdata
      cp -R /usr/local/libdata/perl5/ .

Additional Notes

• Timezone within Perl scripts: Having Perl CGIs trapped within the Chroot means that locale information won't be found so easily, of course backticking system commands won't work either (kinda the point of the chroot). Here's the recipe I use within perl to make sure date/time info uses my timezone:

  use POSIX qw(tzset);
  $ENV{TZ} = 'EST5EDT';
  POSIX::tzset();

  You can possibly get away with copying /usr/share/zoneinfo into the chroot, I tried that in the past and came across a problem I don't remember now, might have been on the right path thought before switching to the above code snippet.
• There are instructions to make use of the OpenBSD Apache Chroot with Perl Scripts that Connect to a Local MySQL Database as well.