Simon Deziel wrote: > On 2017-11-27 09:22 AM, Peter Palfrader wrote: > > On Mon, 27 Nov 2017, Simon Deziel wrote: > > > >> On 2017-11-26 03:31 AM, Peter Palfrader wrote: > >>> The apparmor policy for unbound allows access to > >>> /var/lib/unbound/root.key*, but it does not allow access to any > >>> other dynamically updated key the admin might have put there, > >>> such as debian.org.key on DSA infrastructure. > >>> > >>> Please allow access to all key files. > >> > >> Please see the attached patch. > > > >> # chrooted paths > >> /var/lib/unbound/** r, > >> + owner /var/lib/unbound/*.key* rw, > >> owner /var/lib/unbound/**/*.key* rw, > > > > This would allow /var/lib/unbound/root.key "twice", once via root.key, > > once via *.key. > > Indeed, this patch should be better, thanks Peter.
Hi, I'm a little bit confused here. The unbound daemon runs as user 'unbound', thus it should have read-write permission to the directory /var/lib/unbound/, because that's what the permission on the directory is. Is the apparmor policy intentionally overriding this? There's no requirement that an auto-trust-anchor-file be configured with a filename that ends in ".key". Does the apparmor policy break unbound if a sysadmin doesn't follow this convention? -- Robert Edmonds edmo...@debian.org
