[chrony-dev] [PATCH v4 0/3] chrony in environments unable to adjtime

[Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx>]

There are several conditions which make running chrony in containers a pain
today and this series tries to provide means to handle that.

Motivations:
 - Using ntpd in it's default config in a container caused it to complain in
   syslog about the inability to control the time while at the same time still
   providing a (not great but working) NTP server portion.
   This isn't possible anymore, unless the user sets -x AND drops the Condition
   on CAP_SYS_TIME in the service.
 - Some users would be able to change the config. But often those are mass
   deployments and it is unclear at the time of install (some might even change
   characteristics later in their lifecycle) if a given target system should
   get -x or not. But those users would want ONE (1) config that syncs the
   system clock if it can do so (not -x), but at the same time not fail if
   it can't (In those setups the Host keeps the system clock in sync, so it is
   not mutually exclusive to be "a requirement somewhere" but "not in other
   places" from their POV).
 - Because of the way user namespaces work each container using them starts of
   with a full capability set including CAP_SYS_TIME. However, the adjtimex
   syscall will still fail since the CAP_SYS_TIME capability check is performed
   against the initial user namespace of the host and container will *not* have
   this capability in the host's user namespaces. (See "Capabilities" in [1]
   for more complex details.)
   Without a fix this will let the service run by default (CAP_SYS_TIME is
   present in the users namespace) but then cause it to fail.
   This has unwanted consequences such as causing the default config to fail
   instantly. A very serious problem caused by this is that package upgrades
   which require service restarts to fail.

Until time namespaces are implemented an appropriate and helpful solution to
this problem is to adapt the default config that enables chrony to
intelligently handle such scenarios. This series tries to enable this.

Note:
A totally different approach to this might be to break chronyd from
being a "NTP client/server" service into a more independent entity of a
client and a server.
That would allow the server to run mostly anywhere, while the client portion
obviously only makes sense where it can adjust time.
But due to the fact that currently those are tightly coupled and need each
other in the code that solution isn't anywhere close either.

[1]: http://man7.org/linux/man-pages/man7/user_namespaces.7.html

Christian Ehrhardt (3):
  sys_linux: report if CAP_SYS_TIME is not present
  sys: rework initialisation to return a value
  main: add -X to fall back if time is not adjustable

 doc/chronyd.adoc |  8 ++++++++
 main.c           |  5 ++++-
 sys.c            | 22 ++++++++++++++++++----
 sys_linux.c      | 32 +++++++++++++++++++++++---------
 sys_linux.h      |  2 +-
 sys_macosx.c     |  8 ++++----
 sys_macosx.h     |  2 +-
 sys_netbsd.c     |  8 ++++----
 sys_netbsd.h     |  2 +-
 sys_solaris.c    |  6 +++---
 sys_solaris.h    |  2 +-
 sys_timex.c      | 39 +++++++++++++++++++++++++++------------
 sys_timex.h      | 16 ++++++++--------
 13 files changed, 103 insertions(+), 49 deletions(-)

-- 
2.7.4


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