Re: [chrony-dev] Runtime refclock management

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


On 2017-10-04 6:15 AM, Miroslav Lichvar wrote:
On Tue, Oct 03, 2017 at 02:30:09PM -0400, Will Miles wrote:
I've recently adapted my company's data acquisition platform to use chrony
to manage the local clock.   However, one of the platform features was the
ability to add, remove, or reconfigure time sources such as GPS receivers or
PPS hookups at any time -- so rather than set up some predefined refclock
inputs (SOC0, SOC1, SHM0, etc.) and come up with some external mechanism to
track which ones were in use and by whom, it seemed more straightforward to
extend chrony to allow for "add refclock" and "delete refclock" operations
via chronyc.   I don't know if this will be generally useful - I've only
really tested it with the SOCK refclock - but I thought I'd post it up in
case anyone else was interested.
I think there are cases where this could be useful.

However, there is a problem with permissions. In the current code,
reference clocks are opened before root privileges are dropped, which
means adding refclocks via chronyc would work differently than the
config file. That's not a good user experience. There was a reason why
the SOCK refclock didn't try to remove the socket on exit.

If all refclocks were opened after dropping root privileges, users
would have change permissions/ownership of the devices even if they
were not planning to add them via chronyc. Or, in a worse case, they
would decide to run chronyd with root privileges.

Hm, you are absolutely correct - for refclocks that require specialized kernel IO interfaces like phc or pps, it may not be possible to open them after dropping root privileges.   For "software pipe" refclocks like shm or sock, it's probably less of an issue to limit ownership to a non-root user, but it would still be a breaking change.

To be honest, I hadn't actually tried dropping privileges in my target environment.  I'm actually targeting QNX, albeit a modified kernel where I've hacked in ntp_adjtime() support, so unfortunately the OS support patch set is not helpful for other users.   I know, I know, skipping the security is why we embedded developers have such a poor reputation - shame on me.


What is the best way to submit a patch sequence?   Currently I've got it up
on github at
https://github.com/willmmiles/chrony/commits/client-refclock-add , but I can
do something like git format-patch/git send-email if that's more practical.
Sending patches to the list is prefered.

OK, I will do that in the future.   For a commit chain of several patches, do you prefer one email per patch, or a single message with each patch as an attachment?   I looked through a few months of mailing list history but couldn't find any examples.


Comments are very welcome - if this is a feature you'd be interested in
adopting upstream, but there's further work to do or a different approach
you'd prefer to see, please let me know and I'd be happy to improve it in
whatever way I can.
I had a quick look at the patches and I think the idea is well
implemented. I think I'd have just few comments about coding style,
memory leaks and maybe try to deduplicate some of the code in cmdmon.c
and client.c.

Ah, figures I'd miss a style cleanup somewhere.   Re memory leaks, I didn't thoroughly audit the refclock drivers to ensure everything was freed, but is there something specific you spotted?    Re deduplication, I agree it's an annoyingly large block of marshalling/demarshalling code; I was trying to be consistent with the approach taken for other large packet structures, but I'm definitely open to any opportunity to clean it up.

The parser of the delete command should be able to
handle "refclock" as a hostname for compatibility.

! Yes, of course.   I could use the presence of a third argument to disambiguate.

The Linux seccomp
filter would probably need to be updated to allow all syscalls that
can be made when opening refclocks.

Right.   I don't know much about the current state of security tools in Linux, but that makes sense.


With the permission issue, I'm not sure if this is really worth it.
I'll need to think about it.

Before you implemented the new commands, have you tried modifying the
config file and restarting chronyd? With the dumpdir directive and the
-r option, the timekeeping service should be restored very quickly.

If it didn't work well for you, I'm wondering if it wouldn't be better
to focus on improving this feature instead of adding refclock specific
commands.

To work via the config file, I'd have to:

-> Modify the boot scripts to create a ramdisk and place a base config file in there before starting the daemon, since I don't want to make persistent changes; -> Come up with some kind of mutexing arrangement (lockfiles? another single-threaded daemon processing messages serially?) to avoid multiple time source drivers trying to edit the file in parallel; -> Ensure that the tracking state was preserved across restarts so that esterror and maxerror aren't disturbed -- my application depends not just on accurate time, but also uses the esterror and maxerror values to indicate how much we can trust it; adding a new source shouldn't degrade the existing estimates.   This may already be solved, but I haven't tested it.

From here it seemed to be a lot more straightforward to try and use the existing client message handling framework rather than have to solve parallelism issues via the filesystem, write an additional config file management daemon, and/or fix up any tracking state continuity issues.  But honestly, I agree with you about the permissions -- there be dragons there, and I don't know if there's a solution that doesn't add more complexity than it's worth.   I'm happy to file this under "works for me in my environment, but isn't of use to the general community".

In that vein, I also have a patch stream that adds TAI offset tracking for sources, and implements https://tools.ietf.org/html/draft-stenn-ntp-extended-information-00 to communicate TAI offset information between nodes.   I definitely wouldn't recommend it for use on the public internet, but the foundational patches to transmit and receive NTPv4 extensions might be useful at some future date.   Would it be of any use to post them up here for posterity, even though there's not really much point in merging anything like it now?

Thanks for the review,
-Will



--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/