search

bus1 / dbus-broker

Linux D-Bus Message Broker
https://github.com/bus1/dbus-broker/wiki
Apache License 2.0
675 stars 78 forks source link

Support for systemd dynamic users #266

Closed ya-mouse closed 3 years ago

ya-mouse commented 3 years ago

The systemd supports dynamic users being allocated on service startup and being recycled on service stop. Next start service will (usually) have different uid / gid pair. The dbus-broker caches uid / gid for the provided rules. Once service restarted, the old uid / gid became invalid. What is the reliable way to re-trigger getpwnam/getgrnam?

The possible apporach is:

  1. Provide a config option to specifiy min value for dynamic uid / gid that have could be invalidaded. As well as TTL value for cached dynamic uid / gid.
  2. As long as TTL is not exceeded after last policy check for dynamic uid / gid, use the cached value. If TTL is exceeded, re-trigger getpwnam/getgrnam and update last access timestamp.

The corner case is that old uid / gid might be reused by the other service. As of optimization possibility, we can assume uid / gid are valid as long as the service that owns the bus is connected to dbus. If we can track that, we can invalidate uid / gid once service is disconnected. Any further checks have to be backed by re-triggering of getpwnam/getgrnam.

dvdhrm commented 3 years ago

dbus-broker does not use getpwname or anything related to it. It is only the compatibility launcher dbus-broker-launch that implements the XML policy language of the reference-implementation dbus-daemon. We do not intend to deviate from the reference-implementation regarding our compatibility lanucher. If dynamic-user support is requested for the XML-policy, I recommend talking to upstream dbus-daemon development. The alternative approach is to write a new, independent launcher that no longer follows the reference-implementation.

Regarding dbus-broker itself, you would have to resend an updated policy block on every cache invalidation via the controller API. This would be sufficient to make dbus-broker update to the new UIDs.

Please note that this has been discussed several times before. So far, consensus was to avoid using D-Bus policies with dynamic users. There are just too many caches involved, which all need to be reliably invalidated on every uid-recycle-round. It is not acceptable to delay such invalidations and just hope for the best. Just imagine glib2, glibc, nss-modules, language-runtimes, etc. caching such lookups and returning inconsistent data.

My recommendation is to just do away with strings for uids/gids, as we already do in dbus-broker. String-representations can still be used for debugging or logging.

If you are interested to work on this, I recommend coordinating this with Lennart (systemd) and Simon (dbus-daemon).

ya-mouse commented 3 years ago

Thank you for detailed explanation.

Using numerical uids/gids almost impossible while running on read-only rootfs. Also, too much different configs have to be changed during service restart that use dynamic users. Much easier to pre-allocate dedicated groups (run service with supplimentary group) or even just create dedicated users/groups and avoid dynamic users.