On 6/9/2020 10:51 AM, Paul Theodoropoulos via devel wrote:
On 6/9/2020 3:51 AM, Hal Murray wrote:
I can't figure out how changing something from ntp:ntp to root:ntp is
going to
allow ntpd to read it. Could you say more?
If it tries to read pre-drop root, it is still root and can read
anything. If
it tries to read post-drop-root when it has switched to user ntp, then it
should be able to read files owned by ntp. Changing to root:ntp would
make it
harder to read.
I wish I knew why it worked that way as well, as it's a nonsensical
'permission denied' failure, just as you describe - but it was the only
way I could get ntpsec to start up again.
I'll do some testing.
Yes, it is nonsensical that changing it to root:ntp would make the cert
file harder to read - because that's not what I did.
My certs are generated on a separate pi - my ntpsec webserver for stats.
Once per week, those certs are rsync'ed to my three ntpsec pi's. Those
certs were owned by root:ntp.
My error was in jumping onto the timeserver and looking at the ownership
in /etc/letsencrypt which reflected the above ownership - but ntpsec
hadn't been restarted since those certs were copied over, so it was
happily cruising along with the bad ownerships, since it didn't need to
reread them. Restarting timeservice again threw the error.
Changing /etc/letsencrypt/* to ownership ntp:ntp allows ntpsec to start up
without error. My 1.1.8 timeservers are fine with root:ntp ownership. All
of my timeservers run as user ntp:ntp -
/usr/local/sbin/ntpd -p /run/ntpd.pid -g -u ntp:ntp
Since root can read anything, it's indifferent to ntp:ntp ownership on
startup...
--
Paul Theodoropoulos
www.anastrophe.com
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
