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 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. Emilien 2015-03-20 15:12 GMT+01:00 Emilien Kia <kiae.dev at gmail.com>:> Hello all, > > With a really fast lookup, I think it is probably a problem of NSS > initialization (key loading...) . > As the problem occurs only when upsd is forked and as nss is initialized ( > https://github.com/networkupstools/nut/blob/master/server/upsd.c#L1008)before > upsd deamonify ( > https://github.com/networkupstools/nut/blob/master/server/upsd.c#L1035), > I suspect NSS to not be fork-safe. > > I will intend to look more deeply. > > Best regards, > > Emilien > > > 2015-03-13 13:30 GMT+01:00 Charles Lepple <clepple at gmail.com>: > >> On Mar 12, 2015, at 11:55 PM, Melkor Lord <melkor.lord at gmail.com> wrote: >> >> > >> > On Mon, Mar 2, 2015 at 2:39 AM, Charles Lepple <clepple at gmail.com> >> wrote: >> > >> > > I thought start-stop-daemon was involved because it closes >> stdin/stdout file >> > > descriptors after exec()'ing the daemon. I tried "--no-close" option >> to no >> > > avail. After that, I validated the init script working fine with >> > > UPSD_OPTIONS="-D" in /etc/nut/nut.conf. >> > >> > Not strictly the same as closing the file descriptors, but I tried the >> > following: >> > >> > /sbin/upsd -D >/dev/null 2>&1 < /dev/null >> > >> > And it still worked. So I need to recompile with debugging symbols - >> > the Ubuntu packages did not have them. >> > >> > Sorry to bug you again with this issue but is there any improvement on >> the matter? >> >> No, not yet. >> >> Recompiling with debugging symbols did not reveal anything new. We have >> reached out to the engineer who wrote the NSS code for NUT. >> >> -- >> Charles Lepple >> clepple at gmail >> >> >> >> >> _______________________________________________ >> Nut-upsuser mailing list >> Nut-upsuser at lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser >> > >-------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150320/daa93ce2/attachment.html>
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! 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. If it's convenient, make this part NSS dependent with the usual #ifdef spaghetti :-) to avoid influence on the OpenSSL code. -- Unix _IS_ user friendly, it's just selective about who its friends are. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150321/573793c3/attachment.html>
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 ? BR, Emilien -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150325/b446528f/attachment.html>