4 ms·

The follow up article (https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdDynamicUserDangerous https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdDynami..

by agf 8y ago

The follow up article (https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdDynamicUserDangerous https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdDynami...) explains the underlying problem. Basically, to get around root-only readable directories, a special mount namespace is created when Dynamic Users are used. That fails when there are mount points that systemd can't access, which was due to FUSE filesystems mounted inside owner-only home directories, combined with an NFS mount. This is the second time in a few days that I've heard about systemd-related user / ownership problems. The other was related to when a systemd-managed socket needs to be owned by a user that is created by a daemon that relies on networking to already be up (ldap / activedirectory / whatever). systemd wants to create the socket at the same time as networking is starting, so the user doesn't exist yet -- and there isn't a simple way to tell systemd to delay creating that socket. Instead, the post-start script of the user daemon can chown the socket, and services relying on it will need to be started after that -- and there is no generic way to say to start a service after the auth provider is up, so you have to be specific, making the dependency fragile.

LukeShu 8y ago
> and there isn't a simple way to tell systemd to delay creating that socket. … and there is no generic way to say to start a service after the auth provider is up That's what After=nss-user-lookup.target is for; just stick that in the [Unit] section of the .socket file. See the systemd.special(7) man page for more information. ---- Edit: However, there is an interesting problem related to that: when you use socket activation for the user-providing daemon itself, you'll get a boot deadlock. For instance, one of the common LDAP solutions, nss-pam-ldapd, uses NSS and PAM modules that use a local socket to talk to a daemon (nslcd) that handles actually speaking LDAP. If you adjust that daemon & its service file to use socket activation (a trivial patch), the system will deadlock! Systemd will start the nslcd socket, but then when systemd starts dbus.service as a special hack it will then call dbus_init() to register itself on the bus. This will cause dbus-daemon to use the NSS module and hit the nslcd socket. Since this happens very early, systemd probably hasn't started nslcd itself yet. Because systemd is single threaded, and it's waiting on dbus-daemon to reply, it won't be able to handle the request to start nslcd, and the boot process deadlocks. Eventually, something will time out, and it will hobble along in to a half-working system. You can hack around this by manually ordering nslcd.service before dbus.service.
- zaarn 8y ago
  That should be doable with a single additional line, IIRC Before=dbus.service
  - LukeShu 8y ago
    By itself that would only schedule it before dbus.service if they are both queued to be started; but since we'd like to be using socket activation to lazy-start it, you'll also need to make sure it's queued when dbus.service is queued: [Install] WantedBy=dbus.service That's what I meant by "manually ordering nslcd.service before dbus.service".

by agf 8y ago

LukeShu 8y ago

> and there isn't a simple way to tell systemd to delay creating that socket. … and there is no generic way to say to start a service after the auth provider is up That's what After=nss-user-lookup.target is for; just stick that in the [Unit] section of the .socket file. See the systemd.special(7) man page for more information. ---- Edit: However, there is an interesting problem related to that: when you use socket activation for the user-providing daemon itself, you'll get a boot deadlock. For instance, one of the common LDAP solutions, nss-pam-ldapd, uses NSS and PAM modules that use a local socket to talk to a daemon (nslcd) that handles actually speaking LDAP. If you adjust that daemon & its service file to use socket activation (a trivial patch), the system will deadlock! Systemd will start the nslcd socket, but then when systemd starts dbus.service as a special hack it will then call dbus_init() to register itself on the bus. This will cause dbus-daemon to use the NSS module and hit the nslcd socket. Since this happens very early, systemd probably hasn't started nslcd itself yet. Because systemd is single threaded, and it's waiting on dbus-daemon to reply, it won't be able to handle the request to start nslcd, and the boot process deadlocks. Eventually, something will time out, and it will hobble along in to a half-working system. You can hack around this by manually ordering nslcd.service before dbus.service.

zaarn 8y ago
That should be doable with a single additional line, IIRC Before=dbus.service
- LukeShu 8y ago
  By itself that would only schedule it before dbus.service if they are both queued to be started; but since we'd like to be using socket activation to lazy-start it, you'll also need to make sure it's queued when dbus.service is queued: [Install] WantedBy=dbus.service That's what I meant by "manually ordering nslcd.service before dbus.service".