Fwd: discrete units

[James Browning]

On Wed, Jan 20, 2021, 12:17 PM Hal Murray via devel <devel at ntpsec.org>
wrote:

>
> James Browning said:
> > The permissions required by NTPsec are a mess partly because it is not a
> do
> > one thing well daemon. Instead, you have the Lernean Hydra, which has too
> > many heads and gaining more.
>
> I don't get it.  Could you please say more?  ntpd needs file permissions
> for
> all the files it uses.  That much seems pretty obvious.  Is the problem
> that
> the files are scattered all over the place?
>

Back in the days of ntp1 it was almost that simple. Ntp2 added auth
and monitoring and now we have autokey or nts. I was not using it
before v4.

The one tricky case I can think of is ntpd.log (or whatever you call it).
> If
> you start on a bare system, it gets created with owner root.  Then when
> logrotate comes along, ntpd as user ntpd can't open the new file.  We
> could
> fix that with a bit of code.
>

Create the log with a date suffix and link ntp.log to it or
something? There's code for that there I think...

If it is going to drop-root (a good thing), then ntpd also needs permission
> to
> set the clock.  That part is ugly because it varies with the OS.
>

With a bit of spin from ip/nftables u32 thing[1] all root is needed
for is frobbing time, logs, and shm0/1.

Would it help if we wrote a script to scan ntp.conf and check the file
> permissions and/or the permission for updating the clock?
>
> > I was writing a long blob on how doing too many
> > things was bloating the list of required permissions, but I decided t
> scrap
> > it.
>
> If you still have the text, a short version might be very helpful.
>

I threw it away.

> Also, a rewrite would allow and encourage skipping the problematic parts
> > of singlesock, events, and goprep.
>
> Please say more.
>

I was thinking a complete rewrite would be designed differently and
not be in c. Starting from golang would give us low entry strings,
memory, logging, etc.

====

I imagined that all of the associated time sources except
localclock would be external and feed data to the client via JSON
IPC. The client would then frob the time and feed data via JSON IPC
to the server head(s). The server heads would then possibly only
serve a specific version of a time protocol. I saw
monitoring/control and nts-ke heads off to the side, g/setting data
via the same IPC.

[1] "U32 tests whether quantities of up to 4 bytes extracted from a
packet have specified values. The specification of what to extract
is general enough to find data at given offsets from TCP headers or
payloads."  from iptables-extensions(8)

Let me try sending that to something resembling the right account...

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20210121/bfebf0ef/attachment.htm>