NTP switch in gnome-control-center is broken

[Dan Williams]

On Tue, 2014-10-21 at 20:37 +0200, Lennart Poettering wrote:
> On Fri, 10.10.14 12:20, Dan Williams (dcbw at redhat.com) wrote:
> 
> > I'd love to have timesyncd and resolved from systemd play well with
> > NetworkManager, but unfortunately upstream systemd is not moving very
> > quickly on these services grabbin/accepting information from sources
> > other than systemd-networkd.
> 
> We have been discussing this quite a bit LPC, but we didn't really
> manage to come up with a nice, low-level, synchronous and simple way
> how we could attach this information to network interfaces with good
> lifecycle behaviour, wthout defining a completely new API with
> multiple implementors and whatnot.

Thomas said he talked to Tom about it at LPC but it was mostly
brainstorming.  So it's getting discussed more now, which is great!

> The best idea we had was to use xattrs on /sys/class/net/$NETIF. That
> way, defining new fields of information to pass around would be
> trivial to add, easy to explore from userspace. We'd get
> notifications, and their life-cycle would be bound inherently to the
> one of the kernel objects. It's really close to what we want. There's
> just one problem: only xattrs in the "trusted." namespace are
> supported on /sys (for a good reason, as they are stored in kernel
> memory and thus unpriviliged clients should not be able to attach
> arbitrary numbers of these things to kernel objects), and those may
> not be read by unpriviliged clients. As it turns out though all of
> systemd-networkd, systemd-resolved, systemd-timesyncd run unpriviliged
> as non-root users with no or minimal capabilities on top. Having to
> add CAP_SYS_ADMIN so that they can read the variables added by other
> stacks sounds much less than ideal.
> 
> We could make them work for us by either:
> 
> a) introducing a new "semi-trusted." xattr namespace in the kernel
>    that can only be written to by CAP_SYS_ADMIN, but read by
>    unpriviliged clients
> 
> or 
> 
> b) introducing a new CAP_XATTR_TRUSTED capability or so that allows
>    writing/reading the trusted xattrs.
> 
> But I am not sure who wants to sit down and actually implement that...
> 
> Anyway, other ideas?
> 
> I am really not keen though to do this via dbus, nor via some dir in
> /run (like networkd does) due to the awkward ownership and lifecycle
> semantics.

That was my major issue with resolvconf too, the lifecycle issues.  But
that could be solved via D-Bus connections, where if the client
disconnects, resolved removes the information that client pushed down.

Yes, disconnects happen for various reasons, and two in particular are
worth considering:

1) the DNS source gets kicked off the bus because it sent a
bad/malformed message (eg, non-UTF8-string).  This is bad coding on the
part of the DNS source and should not happen, so I don't consider it a
problem.  Perhaps kdbus is more forgiving here anyway?

2) the DNS source restarts (due to being upgraded, or restarted on
segfault, etc), which ideally should not disrupt networking at all.
This is harder, but since all we're talking about is DNS information and
not connectivity itself, this probably isn't a huge deal either.

For ownership, I don't think that's solved by XATTRs.  Unless you
namespace them or otherwise tie them to the DNS source, all resolved can
do is read the "dns1" attribute on eth0.  But that attribute could be
written to by anything with privilege, be that NetworkManager or
networkd or whatever.  If this isn't what you mean by ownership, could
you elaborate?

Dan