bbeec7361c
The NTP SHM refclock protocol has the following properties: - the memory segments have a predictable key (first segment 0x4e545030) - it's expected to work in any order of starting chronyd and the program providing samples to chronyd, i.e. both the consumer and producer need to be able to create the segment - the producer and consumer generally don't know under which user is the other side running (e.g. gpsd can create the segment as root and also as nobody after it drops root privileges) - there is no authentication of data provided via SHM - there is no way to restart the protocol This makes it difficult for chronyd to ensure it is receiving measurements from the process that the admin expects it to and not some other process that managed to create the segment before it was started. It's up to the admin to configure the system so that chronyd or the producer is started before untrusted applications or users can create the segment, or at least verify at some point later that the segment was created with the expected owner and permissions. There doesn't seem to be a backward-compatible fix of the protocol. Even if one side could detect the segment had a wrong owner or permissions, it wouldn't be able to tell the other side to reattach after recreating the segment with the expected owner and permissions, if it still had the permissions to do that. The protocol would need to specify which side is responsible for creating the segment and the start order would need to strictly follow that. As gpsd (likely the most common refclock source for chronyd) now supports in the latest version SOCK even for message-based timing, update the man page and FAQ to deprecate SHM in favor of SOCK. |
||
|---|---|---|
| .. | ||
| chrony.conf.adoc | ||
| chronyc.adoc | ||
| chronyd.adoc | ||
| faq.adoc | ||
| installation.adoc | ||
| Makefile.in | ||