So, I've got two nearly identical machines, with nearly identical configurations, running unbound-1.2.0, but yet only one of them will start unbound without having the server-key-file and server-cert-file readable by the user unbound runs as after it gets started. The (extremely unhelpful!!! -- I almost had to ktrace to find out which file(s) it's actually complaining about!!!) errors are appended below.
By "nearly identical configurations" I mean I've copied the unbound.conf file from the working machine and only changed the interface and outgoing-interface settings.
Everything else on the two machines is identical, including all file and directory permissions. There are two other client machines, also with very similar configurations, where unbound starts without problems. Only this one machine is giving the error.
It's almost as if on one machine unbound is switching to the unprivileged user earlier on the other.
The only other thing I can think of is something to do with the secondary group privileges the process somehow retains.
Perhaps unbound is not making a call to initgroups(3) or setgroups(2) to clear secondary group privileges and thus retains rights to the "wheel" group, which can in fact read the *.key and *.pem files.
I'm not sure what's different on the machine where unbound fails, but I do note that root does not have any additional groups set, while on the machines where it works, root has additional groups set, including "wheel":
[works] # id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator),20(staff),31(guest)
[fails] # id
uid=0(root) gid=0(wheel)
If this is the significant difference then indeed unbound-1.2.0 is failing to use setgroups(2) or initgroups(3) or best of all setusercontext(3) to ensure the unprivileged process dumps _all_ unnecessary privileges; and then of course it also needs to have already opened all privileged files prior to dropping privileges.