Crash on DNS lookup with Unbound in OpenDKIM
wouter at nlnetlabs.nl
Mon Jan 6 13:03:23 UTC 2020
On 12/30/19 7:41 AM, David Bürgin via unbound-users wrote:
> On 30/12/2019 00:23, Havard Eidnes wrote:
>> What about the directory permissions where that file lives?
>> Libunbound may want to save the updated trust anchors to a new
>> temporary file in the same directory, and would then need write
>> access to the directory. The strategy being to rename the
>> temporary back to the original name afterwards, to get "atomic
>> file system update"-ish semantics.
> You’re right of course, right after posting my message I noticed that
> the autotrust file and directory is owned by user unbound while opendkim
> tries to access it as user opendkim.
> So all is well in the end. Frustrating though that I had to set up a
> full dev environment on the server with debugger and all, just to find
> out about a configuration error. A library just silently shutting down
> my program is not ok in my opinion.
> Could I have found out about my mistake somehow differently?
Good that you found it.
It was an option to set debug mode, that is similar to unbound's verbose
logging feature and would have enabled logs on your code, and then you
could have seen what it was doing. Eg. printing the error about no
permissions to create a temporary file for writing the updated trust
anchor information in the same directory as the trust anchor file.
int ub_ctx_debugout(ctx, FILE*);
int ub_ctx_debuglevel(ctx, verbosity);
are the calls, and this is the same as the verbosity: <value> option in
The issue is that we want to make really sure we can update the trust
anchor. Otherwise the root key might roll, but your application would
not have noticed the error and not be able to write the updated
information. That means it is going to be left with a non-working
rollover endresult, which would only happen very infrequently. But the
permission check is there all the time so we check it straight away, so
you know it can also work when a root key rollover event happens. That
is why it exits (really meant for the unbound daemon itself). Which
also works to signify the problem for library users.
Best regards, Wouter
> Thank you,
> unbound-users mailing list
> unbound-users at lists.nlnetlabs.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Unbound-users