2015-03-26 9:03 GMT+01:00 Arnaud Quette <[email protected]>: > 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" <[email protected]> a écrit : > > > > > > > > > 2015-03-21 17:06 GMT+01:00 Melkor Lord <[email protected]>: > >> > >> > >> On Fri, Mar 20, 2015 at 4:40 PM, Emilien Kia <[email protected]> > 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
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
