From: Miroslav Lichvar Date: Wed, 6 Aug 2025 07:29:38 +0000 (+0200) Subject: doc: update FAQ X-Git-Tag: 4.8-pre1~2 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=487cf3840f2eba5a23e03f5139d6223caf44a430;p=thirdparty%2Fchrony.git doc: update FAQ --- diff --git a/doc/faq.adoc b/doc/faq.adoc index 7c881960..66e58d92 100644 --- a/doc/faq.adoc +++ b/doc/faq.adoc @@ -165,6 +165,13 @@ versions or implementations of the libraries might make different system calls. If the filter is missing some system call, `chronyd` could be killed even in normal operation. +The impact of potential security issues in `chronyc` can be reduced by running +`chronyc` under the _chrony_ user instead of root, or another unprivileged user +if access to the Unix domain socket is not needed. Since version 4.8, `chronyc` +drops root privileges automatically if it is started with the `-u` option +specifying the _chrony_ user, or the name was specified to be the compiled-in +default by the `--with-chronyc-user` option of the configure script. + === How can I make the system clock more secure? An NTP client synchronising the system clock to an NTP server is susceptible to @@ -897,7 +904,9 @@ measurements from both sources. If the first source was significantly better than the second source, it can take many hours before the second source is selected, depending on its polling -interval. You can force a faster reselection by increasing the clock error rate +interval. You can force a faster reselection by reducing the maximum number of +polls the source can still be selected when unreachable (`maxunreach` option +supported since `chrony` version 4.8), increasing the clock error rate (`maxclockerror` directive), shortening the polling interval (`maxpoll` option), or reducing the number of samples (`maxsamples` option).