[Nut-upsuser] SSL only working in DEBUG mode

[Arnaud Quette]

Hey mister M'

A first huge thanks for taking care of this,  and so late in the night. I
know that it's not easy...

(sent from my S3... please excuse my brevity)
Le 25 mars 2015 18:49, "Emilien Kia" <kiae.dev at gmail.com> a écrit :
>
>
>
> 2015-03-21 17:06 GMT+01:00 Melkor Lord <melkor.lord at gmail.com>:
>>
>>
>> On Fri, Mar 20, 2015 at 4:40 PM, Emilien Kia <kiae.dev at gmail.com> wrote:
>>
>>> Some precisions:
>>>
>>> we are not alone, some projects had similar problem:
http://bugs.bitlbee.org/bitlbee/ticket/785
>>> And the problem is really coming from NSS initialization. Discussion
about the issue here :
http://osdir.com/ml/mozilla.crypto/2002-08/msg00016.html
>>
>>
>> Wow! Congratulations on finding the source of the problem, I bet this
wasn't easy!
>
>
> You have done the hardest job. Once you isolate the problem occurs only
when running as a deamon and not in debug mode, searching for a problem is
easier.
> Moreover we have done so many tests on this feature that it is really
surprising we didn't detect this problem before.
> But when we look more precisely at DVT linked by Charles, we can see we
did test only in direct mode, not in deamonized mode.
>
>>
>>
>> I'm glad to see that NUT isn't faulty :-)
>>
>>>
>>> There is a workaround to use NSS with fork but it is more setting a
flag to share some resources (primarily sockets) but must (re)initialize
NSS library on all children.
>>>
>>> AFAIK why we initialize NSS library before becoming user and forking is
to be able to access and read certificates and keys which is readable only
by root and should not be readable in userland. This behavior is this
because it was the behavior used when using OpenSSL. Modifying this
behavior implies to modify key/certificate storage and acces right policy.
>>
>>
>> Well, NUT uses a dedicated unpriviledged user to run ("nut" in my case)
so why not initialize the SSL stuff after forking?
>>
>> Before forking, just check that the SSL cert/key files belong to the
same user as the user which started "upsd" and throw an error message to
the logs if it's not the case to warn the user. Then it's your decision
whether to "disable SSL usage" and continue or refuse "upsd" execution if
conditions are not met.
>>
>
> I will look to do something like that.
>
>>
>>
>> If it's convenient, make this part NSS dependent with the usual #ifdef
spaghetti :-) to avoid influence on the OpenSSL code.
>
>
> What I will do is to move ssl initializing after usering and forking,
than add key file right checking where ssl was initialized before (before
forking).
> As keys should be owned by nut user, this would not be a problem.
> And moving this code, independently of SSL implementation (OpenSSL or
NSS) should work. And will not add more code implementation dependent.
>
> Charles, Arnaud ? Ok with that ?

Works for me at first, but I'll see once yiu push the PR and we have some
tests validating the behavior in daemon mode, including some reload with
added certs (will that work?!)

Thanks again *a lot* and cheers
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150326/7ad39cbc/attachment.html>