On Wed, Mar 07, 2018 at 01:51:31PM +0100, Christian Ehrhardt wrote:
> In unprivileged containers even after e8096330 "sys_linux: don't keep
> CAP_SYS_TIME with -x option" default installations
> will still run without an explicit -x being set and therefore fail by
> missing CAP_SYS_TIME.
> Usually users want services to "just work" which in a non-CAP_SYS_TIME
> environment means that chrony will fulfil just the NTP serving task but
> not the local time control.
> Therefore imply -x in those environments.

I'm not sure about this.

I can see that it would be convenient in some cases to have a service
that automatically falls back to -x, but in the vast majority of cases
I think chronyd is expected to control the clock and if that is not
possible, it should fail.

For example, if I had a docker image with chronyd configured as an NTP
client and I forgot to give it the CAP_SYS_TIME capability, it would
be much likely for me to miss the problem if it fell back to -x.

There are some considerations that should be made before enabling -x.
In order for chronyd to be a good NTP server, the system clock either
needs to be free running (and all applications running on the system
happy with an unsynchronized system clock), or it needs to be
synchronized by another process and chronyd with -x is just serving
the local time (chrony.conf includes the local directive, but no time
sources are specified).

There are other issues with running an NTP client/server in a
container, e.g. network interfaces don't support SW/HW timestamping,
which has an impact on accuracy.

What do others think?

Miroslav Lichvar

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 
Trouble?  Email listmas...@chrony.tuxfamily.org.

Reply via email to