Arranging to chroot a service is a very disruptive procedure. It’s simpler for simple services but harder for complex ones. In the case of Apache, not only would a whole subset of the runtime environment have to be provided to it (and any dynamically loaded modules such as mod_php5), but all the files it needs to serve would also have to be available in the new environment. I wouldn’t be surprised if some of those changes involve rebuilding the software. You would have to understand what a chroot involves in detail. Not an undertaking for a newbie.
On Tue, 2010-03-23 at 21:06 +0000, ken yap wrote:
> Arranging to chroot a service is a very disruptive procedure. It’s
> simpler for simple services but harder for complex ones. In the case of
> Apache, not only would a whole subset of the runtime environment have to
> be provided to it (and any dynamically loaded modules such as mod_php5),
> but all the files it needs to serve would also have to be available in
> the new environment. I wouldn’t be surprised if some of those changes
> involve rebuilding the software. You would have to understand what a
> chroot involves in detail. Not an undertaking for a newbie.
>
>
Another possible option is to use AppArmor
Its live profiling tool can make it easy. A profile tells
AppArmor what a program can (and therefore cannot) access.
You run the program under the auspices of AppArmor and use
it’s Profile tool to see what you need to give the application access
to in order for it to work. Make the edits and save the profile…
then you can force any invocation of the command to always be
under the watchful eye of AppArmor.