On Fri, 10.10.14 12:20, Dan Williams (dcbw@xxxxxxxxxx) 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. 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. Lennart -- Lennart Poettering, Red Hat -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
