ntpd Certificate Loading

[Paul Theodoropoulos]

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