Edit: it's long past my bed time and I should know better. Apologies.

Yes, that's supposed to happen, only root should be messing around with your system clock and changing it.

yea, i figured that.normal users shouldn't change clocks ;)
the error message has some room for improvement ... 'assertion i>=0' could be replaced by 'run as root,you idiot' :)

See OpenNTPd as an existing, battle-tested, simple, secure, reference for proper privilege separation and handling of NTP. It is not broken and may help in your endeavors. This presentation is also interesting. Ntimed should not require root for 100% of its activity.

See OpenNTPd as an existing, battle-tested, simple, secure, reference for proper privilege separation and handling of NTP.

Ouch!

I don't mean to hurt. I mean to draw attention to what OpenNTPd is.. particularly within the context of this issue.

If you don't mean to hurt, you might try assuming that commenters here are generally aware of common UNIX privilege separation techniques, and that this project is a development work in progress.

Sorry if I did not have that assumption to begin with, I will apply that assumption here from now on. Still, I would not agree that the proper techniques are common knowlege. I'm not sure awareness of this issue is even common knowledge.

Either way, if this is already on the roadmap, where does privilege separation fit with respect to other items on the roadmap?

ketzacoatl:

I am a big fan of privilege separation, which is why I invented jails 17 years ago :-)

I'm charitably going to assume that you know at least a little bit about what you are talking about, but I'm going to point out anyway that OpenNTPD is very far from "proper handling ... of NTP" in particular with respect to the timekeeping aspects.

That is a valid trade-off, in particular if the alternative is the full NTPD, and I have no issue with OpenBSD making that decision.

However, my ambitions for ntimed-client are somewhat higher than that, both in terms of time-keeping, but also with respect to portability etc.

To get to your question: Of course the ntimed family of programs will use priv-sep, that's one of the major design-goals, in particular with respect to the ntimed-master and refclock implementations.

For ntimed-client the calculus is more fuzzy.

If my ambitions carry, ntimed-client is going to run on millions of systems, and that means that any small increment of resource usage translates to a non-trivial energy-expenditure and carbon-footprint.

Considering that the relevant NTP packets are very small, contains no text and have a single fixed format, going the full monty to put the NTP packet in one lo-priv process and keep the kernel time-tweaking in a hi-priv process may not be warranted from a power/carbon point if view.

Fortunately my lab is kitted out pretty well to measuring such stuff, and once I have the overall shape of ntimed-client in place, those measurements will guide my decision.

Where lighter weight priv-mgt is availble (CAPSICUM and similar) that should and will obviously be used.

And yes, I'll make for a better diagnostic for the original issue.

@bsdphk, Thank you for the details you have shared here. This is promising!