Brief:
Trying to get dhcp3-server and bind9 to work together nicely.
The "/etc/bind/rndc.key" file is owned by bind:bind w. 640 perms by default and dhcpd3 process runs under user "dhcpd". Adding user "dhcpd" to group "bind" does not seem to work. Permissions of "/etc/bind/rndc.key" need to be changed to 644 for dhcp3-server to start (I could find no other solution - after a few hours of google and 30 minutes of play, at least ;-)

why doesn't this work? what is different when dhcpd is started via it's init script and privs are dropped to the user named dhcpd? i've adjusted the apparmor settings for dhcpd, and there are no audit entries for apparmor being logged - what is preventing this file from being read?

The problem is the profile in /etc/apparmor.d/usr.sbin.dhcpd3, which doesn't allow reading any files in /etc/bind.

Could we have a one-file exception added to this profile, please, to share a key between bind and dhcpd?
The original poster used rndc.key, but I prefer that every use of a key use a unique key, so I think a name such as ddns-key-1.key or (what I use) dhcp.key would be preferable.

As Chuck said, this doesn't seem like something that can be fixed safely for everyone. People can always add the key they want to use to /etc/apparmor.d/usr.sbin.dhcpd and then reload the profile.

Is there a common practice location that we can consider? I think rndc.key is probably out of the question, but does the official upstream or Ubuntu documentation give a standard location? We could consider adding it to the AppArmor profile then.

apparmor.d/usr.sbin.named
apparmor.d/usr.sbin.dhcpd3
both have a line:
/etc/bind/** r, -> apparmor allows them to read the file.

/etc/bind is owned by bind:bind, rwxrwx---
/etc/bind/rndc.key is owned by bind:bind, rw-r----- -> named fails to read the file, dhcpd fails to read the file!!!!

/etc/bind/rndc.key is owned by bind:bind, rw-r--r-- -> (bad idea but: named can read the file, dhcpd can read the file).

I'd say: at the point in time named, dhcpd try to read the file they are running user bind (named), user dhcpd (dhcpd3) but not the required group!
Or: named and dhcpd try to open the file rw, failing because only reading is allowed.

I do believe having the dhcp server setup with dynamic dns is a recommended setup, so I think adding read access to /etc/bind/rndc.key to the dhcp server apparmor profile is a reasonable thing to do. (bug 727837 probably needs to be fixed also for this to ultimately work).

This seems reasonable to me as well. There is no reason to prevent the server from reading rndc.key as it is strictly required by the server when its setup to use rndc. Since we (finally) determined that /etc/bind/rndc.key is the documented place for the file, it makes sense to me to add it to the profile. In reading the various manpages, we should also be including /etc/bind/rndc.conf as well (man rndc.conf).

So, in thinking about and discussing this more, I would like to justify my position somewhat: while I am not super happy about the added permission given to dhcpd, I do think that people who install both dhcpd and bind9 on the same system will tend to use dynamic updates, and at least some of those people are disabling AppArmor to work around this bug, resulting in a decrease in security for these users. For dhcpd servers that don't have bind9 installed (I would imagine most), this change does nothing because rndc.key doesn't exist.

I like this idea much better. Whether packaging creates a special dynamic dns updates key or uses a keys directory, these keys are actually specifically designed for use with dynamic updates and totally appropriate to add to the apparmor profile. Unrelated to this bug, if packaging is being adjusted to make adding dynamic dns work easier, it should probably default to 'off' (which is a secure default) but with a preseedable debconf option to enable it (but this should probably be discussed elsewhere).

Most of the example dynamic dns configs and howtos that are available on the internet aren't secure, as they use the rndc.key and require the dhcpd user to the bind group, both of which compromise security.

A new key should be generated for dynamic dns updates, as described in the dhcpd.conf man page. The key can then be directly included in the config files without requiring apparmor changes.

After some more discussion, what will be allowed is:
/etc/dhcp/ddns-keys/** r,

That directory will be created at install time, owned by root:dhcpd and mode 750. The apparmor rule comment and the changelog will both encourage people to generate separate keys and copy them into that directory.

* New upstream release
* debian/control: reformatted Uploaders so that dch doesn't think I'm making
NMUs
* debian/rules: do a clean between the LDAP-enabled build and the
non-LDAP-enabled one, so that no LDAP-related artefacts are accidently
incorporated into the non-LDAP build
* debian/dhclient-script.*: conditionalise the chown/chmod of the new
resolv.conf on the existence of the old one (closes: #595400)
* debian/dhclient-script.linux: comply with RFC 3442 and ignore
the routers option if the rfc3442-classless-static-routes option is present
(closes: #592735)
* debian/dhclient-script.kfreebsd: fix subnet mask handling (closes: #677985)

* The "Zoe woke up at 4am and I couldn't get back to sleep so I had some
extra time to work on this" release
* patch the Makefile for the embedded BIND libraries so that autoconf is run
so that the modification to configure.in to fix the FTBFS on kFreeBSD
actually does something useful (closes: #643569)