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.

error when not running as root #17

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions