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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Mar 08, 2018 at 12:21:16PM +0100, Christian Ehrhardt wrote:
> 1. if you are in a container you very likely can't set the time.
>     Installing chrony there would silently not start the chrony service for
> lacking CAP_SYS_TIME.
>     - You now installed chrony got no error/warning, but it does nothing.

The systemctl status command seems to print in bold letters that
"start condition failed". 

But this is what users expect in most cases, right? If an NTP
client/server is installed and enabled in a container, it's usually
not intended, e.g. it was installed as a dependency of another
package.

>     - If there are services depending on the chrony service they would not
> start either

Depending on chronyd specifically or the time-sync target? In either
case it probably means they require a synchronized clock. Is it ok to
satisfy that with chronyd -x, which doesn't touch the system clock at
all?

It would be nice if there was some mechanism to pass this information
to containers.

> 2. if you are in busted Host system (or VM) that grants no CAP_SYS_TIME the
> same as above will silently happen.
>     And on a Metal machine or even a VM you'd really want to know it is
> failing, because you'd expect it to work.
> 
> 3. If you are in a container with special privileges that allow
> CAP_SYS_TIME (rare) it is very dangerous to do so.
>     There are no time namespaces for containers to use. Therefore multiple
> containers on that system would start fighting with time adjustments which
> would be the worst IMHO.

That's a good point. Maybe chronyd should print a warning when it
detects something else is messing with the clock. Such check would
probably come at a cost.

> For #1 you want to default to -x if you are in a container

I'd say that applies only to a minority of cases when people actually
want to run an NTP server and chrony wasn't just installed as a
dependency.

> For #2 you want to drop the condition on CAP_SYS_TIME
> For #3 you want to default to -x if you are in a container

I'm not sure about this either. If a container does have CAP_SYS_TIME,
it was probably intended to run an NTP client/server.

> For #4 you want to log a message if the case is detected
> 
> These should be defaults, and admins would be given a way to override this
> behavior.
> This could either be done either:
> - in a Chrony patch to provide this behavior and a cmdline option to
> override.
> - in a wrapper script to the ExecStart of the service file doing the
> checks/messaging and adding -x as needed

It looks complicated and fragile to me.

Would it make sense to simply remove the CAP_SYS_TIME condition from
the unit file and let chronyd fail if it doesn't have it (possibly
with a better error message)?

-- 
Miroslav Lichvar

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