This section looks at some other installation issues you may encounter.
Unix systems usually provide chroot or jail mechanisms, which allow you to run subsystems isolated from the main system. So if a subsystem gets compromised, the whole system is still safe.
Section 23.3.5 includes a few references to articles discussing these mechanisms.
The answer is definitively "no." You can't suid a part of a process. mod_perl lives inside the Apache process, so its UID and GID are the same as those of the Apache process.
You have to use mod_cgi if you need this functionality. See Appendix C for other possible solutions.
Yes, you should. You have to rebuild the mod_perl-enabled server, because it has a hardcoded @INC variable. This points to the old Perl and is probably linked to an old libperl library. If for some reason you need to keep the old Perl version around, you can modify @INC in the startup script, but it is better to build afresh to save you from getting into a mess.
If you are a mod_auth_dbm or mod_auth_db user, you may need to edit Perl's Config module. When Perl is configured, it attempts to find libraries for ndbm, gdbm, db, etc. for the DB*_File modules. By default, these libraries are linked with Perl and remembered by the Config.pm module. When mod_perl is configured with Apache, the ExtUtils::Embed module requires these libraries to be linked with httpd so Perl extensions will work under mod_perl. However, the order in which these libraries are stored in Config.pm may confuse mod_auth_db*. If mod_auth_db* does not work with mod_perl, take a look at the order with the following command:
panic% perl -V:libs
Here's an example:
libs='-lnet -lnsl_s -lgdbm -lndbm -ldb -ldld -lm -lc -lndir -lcrypt';
If -lgdbm or -ldb is before -lndbm (as it is in the example), edit Config.pm and move -lgdbm and -ldb to the end of the list. Here's how to find Config.pm:
panic% perl -MConfig -e 'print "$Config{archlibexp}/Config.pm\n"'
Under Solaris, another solution for building mod_perl- and mod_auth_dbm-enabled Apache is to remove the DBM and NDBM "emulation" from libgdbm.a. It seems that Solaris already provides its own DBM and NDBM, and in our installation we found there's no reason to build GDBM with them.
In our Makefile for GDBM, we changed:
OBJS = $(DBM_OF) $(NDBM_OF) $(GDBM_OF)
to:
OBJS = $(GDBM_OF)
Then rebuild libgdbm before building mod_perl-enabled Apache.
Copyright © 2003 O'Reilly & Associates. All rights reserved.