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>
On Mar 25, 2015, at 1:47 PM, Emilien Kia <kiae.dev at gmail.com> wrote:> 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 ?It is disappointing that NSS cannot easily handle forking - I typically set up Apache+OpenSSL to read the key before dropping root privileges, and it would be nice if NUT could do something similar. But it sounds complicated (I briefly looked at the osdir mailing list thread), and with keys stored in memory either way, you might as well initialize after forking. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150325/645ff745/attachment.html>
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. Discussionabout the issue here : http://osdir.com/ml/mozilla.crypto/2002-08/msg00016.html>> >> >> Wow! Congratulations on finding the source of the problem, I bet thiswasn't easy!> > > You have done the hardest job. Once you isolate the problem occurs onlywhen 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 reallysurprising we didn't detect this problem before.> But when we look more precisely at DVT linked by Charles, we can see wedid 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 aflag 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 isto 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 thesame 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 #ifdefspaghetti :-) 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 orNSS) 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>
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>
On Wed, Mar 25, 2015 at 6:47 PM, Emilien Kia <kiae.dev at gmail.com> wrote: 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. >Given the research you've done on the matter after I reported it, it seems clear to me that you couldn't suspect the NSS lib to misbehave in forked mode beforehand so don't blame anyone except the NSS team :-) -- 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/20150329/6d8135d3/attachment.html>
Hello All 2015-03-26 9:03 GMT+01:00 Arnaud Quette <arnaud.quette at gmail.com>:> > > 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?!) > >Fixed in PR #199 https://github.com/networkupstools/nut/pull/199 Tests are welcome. BR, Emilien -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150404/a9f96b5d/attachment.html>