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