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

[Christian Brauner <christian.brauner@xxxxxxxxxxxxx>]

On Thu, Mar 08, 2018 at 03:59:30PM +0100, Christian Ehrhardt wrote:
> On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx>
> wrote:
> 
> > On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote:
> > > On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx>
> > > > 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.
> > > >
> > >
> > > The people concerned on the link Launchpad bug for example want to serve
> > > time.
> >
> > If they have no other option how to do that, then it's ok. The number
> > of such users is (hopefully) very small.
> >
> > > Hmm if it wouldn't sound as awkward I'd actually say you'd want to split
> > > the client & server services.
> >
> > The client and server are tightly coupled. Some information need to be
> > exchanged between them for each response of the server.
> >
> > > I agree that you'd want to reach time-sync target only after you sync -
> > btw
> > > what does systemd-timesyncd in that case?
> >
> > With timesyncd the time-sync target has almost no meaning. It's
> > reached as soon as the system time is compared with (and possibly
> > restored from) a timestamp saved in a file from previous boot. It does
> > not wait for any responses from NTP servers and the clock will be
> > stepped after the target is reached. As I understand it, it was done
> > this way to avoid delaying the boot.
> >
> > > You mean as the container is not able to steer the clock it's
> > > own time-sync.target should actually be that of its host?
> >
> > Yes, I think that would be nice if it was possible.
> >
> > > Just  as a heads up, due to the crazy world of capabilities some
> > containers
> > > will soon expose CAP_SYS_TIME since it is correct to have the cap for
> > their
> > > space.
> > > But when you actually adjtimex it will fail as it will eventually apply
> > the
> > > hosts caps to it and that you don't have.
> > > This comes at the additional WTF (for me) that checking for CAP_SYS_TIME
> > > has effectively lost almost all its meaning :-/
> >
> > Interesting. Is this described anywhere?
> >
> 
> For this answer I'm reaching out to a few of said "they can explain better"
> people :-)
> @Stephane / @ Christian - could one of you outline what is going on in the
> container world in better words that I'm able to.
> Mind you - the list requires subscription.

Right, container that use user namespaces **always** start off with a full
capability set including CAP_SYS_TIME unless they are explicitly
dropped. The kernel will enforce the correct permissions automatically so
dropping a given capability is not needed. The problem is that
capabilites are sometimes checked against the initial user namespace and
sometimes against the current user namespace. The reason for this is
that while some parts of the kernel are already namespaced (mount
tables, networks etc.) others are not. Allowing access to non-namespaced
kernel resources from a non-initial user namespace is almost always a
security vulnerability. Since time is non-namespaced resource it cannot
be allowed to change it from a non-initial user namespace since it would
affect the whole system. However, it is expected that there will be a
concept of a time namespace in the future. For most non-namespaced
resources applications that are expected to run in user namespaces
(systemd, lxc, etc.) follow the concept of "seek forgiveness, not
permission" meaning one should usually check whether an operation is
possible and if it is not move on or fallback to another more
appropriate mode. Now, this is of course an application-by-application
decision. Now, I think it would make sense for chrony to be a "seek
forgiveness, not permission" application since a) it is expected to be
run in user namespaces and b) there'll be a time-namespace. Actually a
good friend of mine from Red Hat is looking into this. :)

Christian

> 
> 
> > > Btw - for the reason above (haivng the cap, but not able to set time) is
> > > there any way to adjtimex, but
> >
> > Check if adjtimex() works before chronyd is started? The adjtimex(8)
> > utility could be used for that.
> >
> > > An additional default-off option to then in turn disable syncing the
> > clock
> > > would be my perfect solution.
> > > Can we disable it so late, as I thought we detect the inability to do so
> > > rather late?
> > > That way people could opt-in to a "instead of the (now better) failure, I
> > > want it to run on less accuracy in pure server mode"
> > >
> > > How about that?
> >
> > I'd rather keep it simple and avoid implementing an automatic fallback
> > in chrony.
> >
> > --
> > 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.
> >
> >
> 
> 
> -- 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

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