03.10.2014 20:52, Robert Edmonds wrote:
> Hi, Michael:
>
> Michael Tokarev wrote:
>> unbound server logs a warning like this:
>>
>> unbound[616]: [616:0] error: could not open autotrust file for writing,
>> /var/lib/unbound/root.key.616-0: Permission denied
[]
>> Note that while the unbound.conf manpage says this _file_ should be
>> writable, it looks like the _directory_ where the file resides should
>> be writable instead, since unbound performs create+rename instead of
>> rewriting.
>
> Hm, this directory is chown'd to unbound:unbound in the postinst. I
> guess there is some way the ownership is getting reset.
>
>> So I think the fix is to chown /var/lib/unbound not
>> /var/lib/unbound/root.key.
Aha. I see what's going on.
if [ "$1" = configure ]; then
if ! getent passwd unbound >/dev/null; then
adduser --quiet --system --group --no-create-home --home
/var/lib/unbound unbound
chown unbound:unbound /var/lib/unbound
fi
I think this chown should go outside of the if statement.
For a very rare case like this one, when I had unbound user
pre-populated in my /etc/passwd from another machine..
Or just close this bugreport right away, since this situation
is very unlikely.
I missed this chown on the directory in postinst, I noticed only
the root.key chown down a few lines.
Thanks,
/mjt
>> And to run unbound-anchor as unbound user there too, to stop chown'ing
>> the key file.
>
> Yes, that makes sense to me.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
