[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.


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