[chrony-dev] [GIT] chrony/chrony.git branch master updated. 4.3-31-gbbeec73 |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
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 <mlichvar@xxxxxxxxxx>
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 <mlichvar@xxxxxxxxxx>
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-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.