On Sat, 21 Apr 2001, Ethan Benson wrote: > seriously though, it makes alot more sense for your chroot package to > build a chroot jail, maybe do something about the config files, and > then just divert the /etc/init.d/bind script elsewhere and replace it > with one that installs the bind binaries into the chroot and then > starts bind from there. this way you need not include any bind > binaries in your package so your package won't need to be updated > every time bind gets a security update. instead the mainline bind > package would be updated by the security team, it would upgrade > /usr/sbin/named* and run /etc/init.d/bind restart in its postinst, > when that happens your initscript would copy the new updated binaries > into the chroot and restart them. >
I see. > if your package is a complete fork of the mainline package the > security team now has two bind packages to fix instead of one. given > how busy they tend to be i think its prudent to avoid creating more > work for them unecessarily. > Good point. > also your initscript should update certain things in the chroot at > every start anyway, things like /etc/localtime so the logs have > correct timestamps and the admin doesn't have to remember to update > two /etc/localtimes if the default timezone should need to be > changed. libc is another that needs to be updated in the chroot jail. > > Aargh! I've just realized that with /etc/localtime only being copied at debianization time, all users of my package effectively have America/New York as their timezone. So some kind of script will be necessary in any case so we might as well go all the way. As for libc, I compiled the libraries statically. The idea was that eventually they would be compiled with stackguard or something for a little extra protection against buffer overflows (this doesn't give 100% protection I know.) but I never got around to implementing that. -- Jaldhar H. Vyas <[EMAIL PROTECTED]>