Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On Thu, 25 Apr 2024 at 07:58, Rasmus Villemoes wrote: > > On 23/04/2024 13.23, Colin Watson wrote: > > On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > >> According to systemd.special(7) > >> > >> nss-user-lookup.target > >> > >> A target that should be used as synchronization point for all > >> regular UNIX user/group name service lookups. [...] All > >> services for which the availability of the full user/group > >> database is essential should be ordered after this target, but > >> not pull it in. All services which provide parts of the > >> user/group database should be ordered before this target, and > >> pull it in. > >> > >> I have a custom .service that does exactly as described in the second > >> part, i.e. provides part of the user/group database and says > >> Before=nss-user-lookup.target, Wants=nss-user-lookup.target > >> (concretely, it modifies /etc/shadow to update a default password, but > >> that's not really important). I believe sshd definitely belongs in the > >> former category, i.e. sshd should not be started until any such > >> service that updates the user/group database, such as updating > >> /etc/shadow, have run. > >> > >> Hence the ssh.service and ssh.socket files should add > >> > >> After=nss-user-lookup.target > >> > >> in their [Unit] sections. This is a no-op on systems that do not have > >> any service pulling in that target, but required for correctness on > >> systems that do. > >> > >> Of course, I could, and currently do, handle this via a drop-in config > >> fragment in some ssh.service.d/ directory. But this, and other similar > >> synchronization targets, exist so that one does not necessarily need > >> to know about every other service running on the system. > > > > This sounds like a reasonable proposal to me. I'm just CCing Debian's > > systemd maintainers for a quick review to make sure I'm not missing > > anything subtle. > > > > Thanks. > > I was a bit worried about not adding the After= to the socket, as I > assumed that when the sshd@foobar.service would be started "manually" > (i.e. activated by the socket unit), it would not form part of the whole > initial transaction and hence the sshd@.service's own After= > relationship would not be honored. > > But testing shows I was wrong, and indeed one can establish a connection > to port 22, but the sshd@foobar.service is then marked as waiting until > the appropriate target is reached. > > That said, I'm not sure there is that much value in enabling the socket > allowing connections to come in early, but it's not wrong wrt. > correctness. It's mostly a matter of what UX is better in case a > prerequisite for sshd takes a longish time to get up: not listening at > all on port 22, or accept connections but then just make it hang. The reason is to avoid connections failing because there's nothing open, and instead let them queue waiting for the service for a bit longer, which is better than retrying
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On 23/04/2024 13.23, Colin Watson wrote: > On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: >> According to systemd.special(7) >> >> nss-user-lookup.target >> >> A target that should be used as synchronization point for all >> regular UNIX user/group name service lookups. [...] All >> services for which the availability of the full user/group >> database is essential should be ordered after this target, but >> not pull it in. All services which provide parts of the >> user/group database should be ordered before this target, and >> pull it in. >> >> I have a custom .service that does exactly as described in the second >> part, i.e. provides part of the user/group database and says >> Before=nss-user-lookup.target, Wants=nss-user-lookup.target >> (concretely, it modifies /etc/shadow to update a default password, but >> that's not really important). I believe sshd definitely belongs in the >> former category, i.e. sshd should not be started until any such >> service that updates the user/group database, such as updating >> /etc/shadow, have run. >> >> Hence the ssh.service and ssh.socket files should add >> >> After=nss-user-lookup.target >> >> in their [Unit] sections. This is a no-op on systems that do not have >> any service pulling in that target, but required for correctness on >> systems that do. >> >> Of course, I could, and currently do, handle this via a drop-in config >> fragment in some ssh.service.d/ directory. But this, and other similar >> synchronization targets, exist so that one does not necessarily need >> to know about every other service running on the system. > > This sounds like a reasonable proposal to me. I'm just CCing Debian's > systemd maintainers for a quick review to make sure I'm not missing > anything subtle. > Thanks. I was a bit worried about not adding the After= to the socket, as I assumed that when the sshd@foobar.service would be started "manually" (i.e. activated by the socket unit), it would not form part of the whole initial transaction and hence the sshd@.service's own After= relationship would not be honored. But testing shows I was wrong, and indeed one can establish a connection to port 22, but the sshd@foobar.service is then marked as waiting until the appropriate target is reached. That said, I'm not sure there is that much value in enabling the socket allowing connections to come in early, but it's not wrong wrt. correctness. It's mostly a matter of what UX is better in case a prerequisite for sshd takes a longish time to get up: not listening at all on port 22, or accept connections but then just make it hang. Rasmus
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On Tue, 23 Apr 2024 12:23:21 +0100 Colin Watson wrote: > On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > > According to systemd.special(7) > > > > nss-user-lookup.target > > > > A target that should be used as synchronization point for all > > regular UNIX user/group name service lookups. [...] All > > services for which the availability of the full user/group > > database is essential should be ordered after this target, but > > not pull it in. All services which provide parts of the > > user/group database should be ordered before this target, and > > pull it in. > > > > I have a custom .service that does exactly as described in the second > > part, i.e. provides part of the user/group database and says > > Before=nss-user-lookup.target, Wants=nss-user-lookup.target > > (concretely, it modifies /etc/shadow to update a default password, but > > that's not really important). I believe sshd definitely belongs in the > > former category, i.e. sshd should not be started until any such > > service that updates the user/group database, such as updating > > /etc/shadow, have run. > > > > Hence the ssh.service and ssh.socket files should add > > > > After=nss-user-lookup.target > > > > in their [Unit] sections. This is a no-op on systems that do not have > > any service pulling in that target, but required for correctness on > > systems that do. > > > > Of course, I could, and currently do, handle this via a drop-in config > > fragment in some ssh.service.d/ directory. But this, and other similar > > synchronization targets, exist so that one does not necessarily need > > to know about every other service running on the system. > > This sounds like a reasonable proposal to me. I'm just CCing Debian's > systemd maintainers for a quick review to make sure I'm not missing > anything subtle. That sounds fine - maybe the service, but not the socket, so that connections can start to come in early. I also note there's accountsservice pulling that target in but it shouldn't, but that's a separate matter and can be handled upstream. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > According to systemd.special(7) > > nss-user-lookup.target > > A target that should be used as synchronization point for all > regular UNIX user/group name service lookups. [...] All > services for which the availability of the full user/group > database is essential should be ordered after this target, but > not pull it in. All services which provide parts of the > user/group database should be ordered before this target, and > pull it in. > > I have a custom .service that does exactly as described in the second > part, i.e. provides part of the user/group database and says > Before=nss-user-lookup.target, Wants=nss-user-lookup.target > (concretely, it modifies /etc/shadow to update a default password, but > that's not really important). I believe sshd definitely belongs in the > former category, i.e. sshd should not be started until any such > service that updates the user/group database, such as updating > /etc/shadow, have run. > > Hence the ssh.service and ssh.socket files should add > > After=nss-user-lookup.target > > in their [Unit] sections. This is a no-op on systems that do not have > any service pulling in that target, but required for correctness on > systems that do. > > Of course, I could, and currently do, handle this via a drop-in config > fragment in some ssh.service.d/ directory. But this, and other similar > synchronization targets, exist so that one does not necessarily need > to know about every other service running on the system. This sounds like a reasonable proposal to me. I'm just CCing Debian's systemd maintainers for a quick review to make sure I'm not missing anything subtle. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
Package: openssh-server Version: 1:8.9p1-3ubuntu0.6 Severity: normal Dear Maintainer, According to systemd.special(7) nss-user-lookup.target A target that should be used as synchronization point for all regular UNIX user/group name service lookups. [...] All services for which the availability of the full user/group database is essential should be ordered after this target, but not pull it in. All services which provide parts of the user/group database should be ordered before this target, and pull it in. I have a custom .service that does exactly as described in the second part, i.e. provides part of the user/group database and says Before=nss-user-lookup.target, Wants=nss-user-lookup.target (concretely, it modifies /etc/shadow to update a default password, but that's not really important). I believe sshd definitely belongs in the former category, i.e. sshd should not be started until any such service that updates the user/group database, such as updating /etc/shadow, have run. Hence the ssh.service and ssh.socket files should add After=nss-user-lookup.target in their [Unit] sections. This is a no-op on systems that do not have any service pulling in that target, but required for correctness on systems that do. Of course, I could, and currently do, handle this via a drop-in config fragment in some ssh.service.d/ directory. But this, and other similar synchronization targets, exist so that one does not necessarily need to know about every other service running on the system. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.136-6-g3d6db53ae88c (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.118ubuntu5 ii debconf [debconf-2.0] 1.5.79ubuntu1 ii dpkg 1.21.1ubuntu2.3 ii init-system-helpers1.62 ii libaudit1 1:3.0.7-1build1 ii libc6 2.35-0ubuntu3.6 ii libcom-err21.46.5-2ubuntu1.1 ii libcrypt1 1:4.4.27-1 ii libgssapi-krb5-2 1.19.2-2ubuntu0.3 ii libkrb5-3 1.19.2-2ubuntu0.3 ii libpam-modules 1.4.0-11ubuntu2.4 ii libpam-runtime 1.4.0-11ubuntu2.4 ii libpam0g 1.4.0-11ubuntu2.4 ii libselinux13.3-1build2 ii libssl33.0.2-0ubuntu1.15 ii libsystemd0249.11-0ubuntu3.12 ii libwrap0 7.6.q-31build2 ii lsb-base 11.1.0ubuntu4 ii openssh-client 1:8.9p1-3ubuntu0.6 ii openssh-sftp-server1:8.9p1-3ubuntu0.6 ii procps 2:3.3.17-6ubuntu2.1 ii ucf3.0043 ii zlib1g 1:1.2.11.dfsg-2ubuntu9.2 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 249.11-0ubuntu3.12 ii ncurses-term 6.3-2ubuntu0.1 ii ssh-import-id5.11-0ubuntu1 ii xauth1:1.1-1build2 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere ii ssh-askpass 1:1.2.4.1-13 ii ssh-askpass-fullscreen [ssh-askpass] 0.3-3.1build2 ii ssh-askpass-gnome [ssh-askpass] 1:8.9p1-3ubuntu0.6 ii ufw 0.36.1-4ubuntu0.1 -- debconf information excluded
