[Nut-upsuser] SSL only working in DEBUG mode

[Emilien Kia]

2015-03-26 9:03 GMT+01:00 Arnaud Quette <arnaud.quette at gmail.com>:

> 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
>

After looking a bit deeply, we have another little problem. When we intend
to start upsd with the init script (at least under debian-based distrib -
tested on Linux Mint 17.1) when we have the NSS problem, the init script
exit with the "[OK]" state even if the "real" deamon process does not run
correctly.

Perhaps we could add some tests to validate if the deamonization is OK. But
it is a little bit out of my competencies (I am not a bash and
linux-init-process expert).

Emilien
-------------- section suivante --------------
Une pi�ce jointe HTML a �t� nettoy�e...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150326/1d8fab02/attachment-0001.html>