Comment 6 for bug 1086775

OK so my working hypothesis is this. On Lucid /var/cache/bind is created simply by virtue of it being a directory within the package (see the bind9.list file). The group write permission is added by the postinst. If the Lucid package was installed, then removed, then installed again, the following happens:

1. the first install would create /var/cache/bind with whatever ownership is in the package, and also /etc/bind/rndc.key with root ownership. The postinst thens runs and fixes the group write permission on /var/cache/bind.

2. the removal would delete /var/cache/bind as it is not a conffile, but not /etc/bind/rndc.key

3. the second install would create /var/cache/bind again with (possibly) the wrong permissions, and the postinst script would not fix it.

This probably doesn't go wrong in Lucid because nothing writes to the cache directory and/or bind survives without the cache. It's certainly empty here on our Lucid boxes pre upgrade to Precise. But the Precise upgrade requires to write there, and then dies.

The above would happen (AFAICT) if *ANY* version ever released of the Lucid bind9.deb had broken permissions, as subsequent upgrades would not fix it.

The problem with only fixing permissions if some rather random file in /etc/ is owned by root is it is inherently fragile. Is there any reason why the bind cache directory should ever not be writeable by the group that owns it?