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
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.
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
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
Lennart Poettering, Red Hat