On Tue, 31 Aug 2004, Joe Cooper wrote:
resolve.conf) that Squid relies on (it could be that shared libraries are pulled in before Squid chroots, and so they might not be needed--Henrik wrote the chroot code I think, or at least maintains it now, maybe he'll chime in with clarification).
If you use the chroot directive in squid.conf then only logs, cache and a dev/null node is minimally required within the chroot directory structure. It is also a good idea to set up a syslog socket within the chroot (man syslogd).
The squid configuration file and any data referenced from there should be outside of the chroot directory, and unless you use any helpers no libraries is required either.
If you use helpers then the helper binaries and any libraries, configuration files etc used by these helpers is required within the chroot.
It should be noted that while Squid is running with a chroot directive there is two layers of security added to your system not otherwise present
a) Squid is chrooted to the specified directory.
b) All traces of any root privileges is irreversibly revoked, making sure that any hypothetical attack on Squid can not break out of the chroot.
And yes, I both wrote and maintain this part of Squid as I am a strong follower of chrooting network services but also very much dislike the hazards and trouble of creating manual chroots using the chroot command.
An alternative to the chroot directive in squid.conf is to use my chroot dynamic wrapper. <url:http://chrootsafe.sourceforge.net/>. This wrapper can chroot any application in a sane manner with very little effort. But for Squid it is simpler to use the chroot directive in squid.conf.
chroot_safe is used by several projects providing anonymous cvs pserver access in a secure manner.
Regards Henrik
