On Tue, 2014-10-21 at 20:37 +0200, Lennart Poettering wrote:
On Fri, 10.10.14 12:20, Dan Williams (dcbw(a)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