Re: [chrony-dev] [PATCH] main: imply -x if time can't be set

On Wed, Mar 7, 2018 at 3:43 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

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.

I thought that having the server portion work by default would be very nice to user.

But I agree that if time there is like "really bad" then it has to be an explicit opt in by user/tool that sets it up.

So the question is, is this "so bad" that we should not fall back by default.

Or is this a minor degradation and the comfort for the NTP server component to just work outweighs the concern.

What do others think?

Absolutely, me as well.

P.S. if this will be a tradeoff we can't decide (but really only then) - how about adding a new cmdline option to enable (or disable) this new behavior.

That would allow downstreams to decide if they want either or the other behavior.

--
Miroslav Lichvar

--
To unsubscribe email chrony-dev-request@chrony.tuxfamily.org with "unsubscribe" in the subject.
For help email chrony-dev-request@chrony.tuxfamily.org with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxx.org.

Christian Ehrhardt

Software Engineer, Ubuntu Server

Canonical Ltdh