Perl Chroot'd Environment

I downloaded and compiled perl with the install path pointing to my chroot'd webroot /chroot/usr/local . I then setup a new external application that uses the lsperl fastcgi module and created a script handler for it. When I attempt to run a very simple hello world perl script "test.pl" I get "503 Service Unavailable"??? I checked the perl binary located in the chroot to see what shared libraries it was using and verified that those libraries are located in the chroot as well.

Thanks for the suggestions mistwang. The script did run successfully using the chroot command. I double checked all the shared libs reported by strace as well. I did notice something strange in the stderr.log

lscgid: execve(): No such file or directory

Click to expand...

I checked the lsperl fastcgi module and it seems it was pointing to /usr/bin/perl, however the perl binary is located in /usr/local/bin. I changed the shebang to use #!/usr/local/bin/perl then loaded the FCGI.pm module using cpan. Now I'm getting the following message:

mistwang,
Still having some problems getting Perl to work in a chroot'd environment using the Pro version. I've copied /usr/lib/perl5 directory into my chroot directory /chroot/usr/lib/perl along with all the any binaries etc. running the command "chroot /chroot perl -V" reports back the following

I think there still are missing libraries/files that used by perl at runtime, you can try run the lsperd inside jail, it may require a fcgi start, like the "cgi-fcgi" comes with the fastcgi-2.4 package. Please refer its man page.

you can try "chroot /chroot strace cgi-fcgi -start <socketaddr> <path_to_lsperld.fpl>", and you can do the same outside of the jail and compare the output.

chroot.sh trys to copy those required files into the jail, it works on Redhat 9, but file locations is different in different linux distribution, you may read the chroot.sh and make sure all files has been copied over.

mistwang,
I don't believe the problem is with the perl environment setup in the chroot. The reason is that if I execute the script as a CGI vs lsws it works fine. I seem to be only getting the failure when attempting to use the lsperld.fpl script to run it as fastcgi.

After running lsperld.fpl as you suggested and comparing the output from each I could only find one small difference. Running in the chroot the strace revealed "--- SIGCHLD (Child exited) @ 0 (0) ---". This was the only difference from the entire trace. I compared line by line and verified each lib reference that was used.

I'm not sure what I should be looking for now, however I think if I can find another fastcgi script I'll validate it against my environment setup. If it works then I know the problem is with lsperld.fpl somewhere..

Currently I'm testing with a version I compiled and installed (Perl 5.8.7). For the build, I compiled and installed Perl under /usr/local/. Once complete I copied the libs from /usr/local/perl into the chroot /chroot/usr/local/perl. I also moved all the binaries into there respective location as well.

I tested perl under the chroot using "chroot /chroot perl -V" and by running a couple simple scripts under the chroot as well. Everything seems fine and working.

I then modified the lsperld.fpl shebang to use #!/usr/local/bin/perl instead of #!/usr/bin/perl. However I still get the 503 error.

I've been able to run Perl scripts under CGI in the chroot'd environment without any problems via LSWS but creating a context definition. I even tried running a very simple Perl script that uses FCGI and it runs fine under CGI (see example) using LSWS.

I might try a clean install from scratch this weekend if I can't get it working on my test box. I'm sure it's just a missing library somewhere as you suggested. The problem is finding it. I didn't think chrooting a webserver was this much work, however in the end it'll be worth it from a security standpoint. Thanks again for your continued assistance.

When you straced the lsperld.fpl, you actually traced the cgi-fcgi or whatever the fcgi spawner you used, not the lsperld.fpl itself. You should either let strace to trace children process by adding an command line option, or do something like "cgi-fcgi ... strace ./lsperld.fpl".

Once you master how to use strace properly, you can figure out this kind of problem easily, no matter it is perl, python, or ruby, etc.

Please let me know what libraries/files are missing after you figured it out.

mistwang,
Thanks for the assistance. Instead of spending countless hours trying to figure out which library it was causing the issue I just reinstalled RH9, LSWS and Perl. Setup the chroot environment for LSWS and copied all the Perl stuff into the chroot enviroment. It worked perfectly..

I just hope that it goes this smooth for me on the production server.. That's one machine I can't reinstall from scratch. :lol: