Re: chroot bind?
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 <jaldhar@debian.org>
Reply to: