This is an automated email from git. It was generated because a ref change was pushed to the "chrony/chrony.git" repository.
The branch, master has been updated via bbeec7361c339090cbca0356b83a4131f9b4502a (commit) via 6fba5a4a7fbe785849c0ec759e18bce0b7e234e4 (commit) from 26889a8cb7ce661ff22998b339b95214c88c3319 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit bbeec7361c339090cbca0356b83a4131f9b4502a Author: Miroslav Lichvar <mlich...@redhat.com> Date: Thu Jan 12 15:23:21 2023 +0100 doc: deprecate SHM refclocks in favor of SOCK 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. commit 6fba5a4a7fbe785849c0ec759e18bce0b7e234e4 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Tue Jan 10 15:02:49 2023 +0100 examples: add chronyd-restricted.service This is a more restricted version of the chronyd service intended for minimal NTP/NTS client configurations. The daemon is started without root privileges and is allowed to write only to its own runtime, state, and log directories. It cannot bind to privileged ports in order to operate as an NTP server, or provide monitoring access over IPv4/IPv6. It cannot use reference clocks, HW timestamping, RTC tracking, and other features. ----------------------------------------------------------------------- Summary of changes: doc/chrony.conf.adoc | 68 +++++++++++++++++++++++-------------- doc/faq.adoc | 44 ++++++++++++++---------- examples/chronyd-restricted.service | 59 ++++++++++++++++++++++++++++++++ 3 files changed, 128 insertions(+), 43 deletions(-) create mode 100644 examples/chronyd-restricted.service hooks/post-receive -- chrony/chrony.git -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.