[Unbound-users] riddle me this: why does one machine fail to start SSL for the control channel?

[Greg A. Woods; Planix, Inc.]

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.

-- 
					Greg A. Woods; Planix, Inc.
					<woods at planix.ca>

Jan 31 14:55:09 historically unbound: [2019:0] error: Error setting up  
SSL_CTX key and cert crypto error:0200100D:system  
library:fopen:Permission denied
Jan 31 14:55:09 historically unbound: [2019:0] error: and additionally  
crypto error:20074002:BIO routines:FILE_CTRL:system lib
Jan 31 14:55:09 historically unbound: [2019:0] error: and additionally  
crypto error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system  
lib
Jan 31 14:55:09 historically unbound: [2019:0] error: util/alloc.c at  
131 could not pthread_spin_destroy(&alloc->lock): Invalid argument
Jan 31 14:55:09 historically unbound: [2019:0] fatal error: Could not  
initialize main thread

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20090131/3fbb409f/attachment.bin>