"systemd --user" fails to start for non-local users

[Andy McVey]

systemd-logind fails to start the systemd --user process for non-local users on Ubuntu 20.04. This is a reproducible problem; all our systems are displaying the same symptoms.

The systems are using Kerberos (Active Directory) for authentication, and NIS for account meta-data and authorisation (groups)

A base installation is performed using the server 20.04 ISO image. No additional packages are selected. Post-install, I run:

apt-get install tcsh nis krb5-user libpam-krb5 libnss-systemd

I set up the NIS client (supply the default domain name, check ypbind is running and ypcat passwd is working)

I then set up /etc/krb5.conf for kerberos authentication to a domain controller, confirm that kinit works and a kerberos ticket is issued.

I modify /etc/passwd, /etc/group and /etc/shadow, appending a "+" to the end of each.

/etc/nsswitch.conf is modified to support compat mode, as well as systemd:

passwd: compat systemd
group: compat systemd
shadow: compat

I can log in remotely via ssh using my NIS account and Kerberos credentials. MY NIS meta-data looks like:

amcvey:KRB5:<UID>:<GID>:Andy McVey:/home/amcvey:/bin/tcsh

(where UID and GID are replaced with values unique to the organisation)

On login, the following occurs:

hostname:~> systemctl --user
Failed to connect to bus: No such file or directory

I put pam-systemd and systemd-logind into debug mode to get more information:

Feb 12 09:51:32 myhostname sshd[1210]: Accepted publickey for amcvey from [redact] port 58849 ssh2: RSA SHA256:[redact]
Feb 12 09:51:32 myhostname sshd[1210]: pam_unix(sshd:session): session opened for user amcvey by (uid=0)
Feb 12 09:51:32 myhostname systemd-logind[903]: Got message type=method_call sender=:1.13 destination=org.freedesktop.login1 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=CreateSession cookie=2 reply_cookie=0 signature=uusssssussbssa(sv) error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): pam-systemd initializing
Feb 12 09:51:32 myhostname systemd-logind[903]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=GetConnectionUnixUser cookie=40 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): Asking logind to create session: uid=198083 pid=1210 service=sshd type=tty class=user desktop= seat= vtnr=0 tty= display= remote=yes remote_user= remote_host=10.105.121.110
Feb 12 09:51:32 myhostname systemd-logind[903]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.6 path=n/a interface=n/a member=n/a cookie=13 reply_cookie=40 signature=u error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a
Feb 12 09:51:32 myhostname systemd-logind[903]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=GetConnectionUnixProcessID cookie=41 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): Failed to create session: No such process
Feb 12 09:51:32 myhostname systemd-logind[903]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.6 path=n/a interface=n/a member=n/a cookie=14 reply_cookie=41 signature=u error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname systemd-logind[903]: Unable to connect to /run/systemd/userdb/io.systemd.Multiplexer: No such file or directory
Feb 12 09:51:32 myhostname systemd-logind[903]: n/a: varlink: setting state idle-client
Feb 12 09:51:32 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: Sending message: {"method":"io.systemd.UserDatabase.GetUserRecord","parameters":{"uid":198083,"service":"io.systemd.DynamicUser"}}
Feb 12 09:51:32 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state idle-client → awaiting-reply
Feb 12 09:51:32 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: New incoming message: {"error":"io.systemd.UserDatabase.NoRecordFound","parameters":{}}
Feb 12 09:51:32 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state awaiting-reply → processing-reply
Feb 12 09:51:32 myhostname systemd-logind[903]: Got lookup error: io.systemd.UserDatabase.NoRecordFound
Feb 12 09:51:32 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state processing-reply → idle-client
Feb 12 09:51:32 myhostname systemd-logind[903]: Sent message type=error sender=n/a destination=:1.13 path=n/a interface=n/a member=n/a cookie=42 reply_cookie=2 signature=s error-name=org.freedesktop.DBus.Error.UnixProcessIdUnknown error-message=No such process
Feb 12 09:51:32 myhostname systemd-logind[903]: Failed to process message type=method_call sender=:1.13 destination=org.freedesktop.login1 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=CreateSession cookie=2 reply_cookie=0 signature=uusssssussbssa(sv) error-name=n/a error-message=n/a: No such process

So it seems logind is trying to get the PID of the calling (sshd?) process and failing. What's strange is that if I add my NIS entry directly to /etc/password it works. systemctl --user works, and the following appears in the logs:

Feb 12 09:59:20 myhostname sshd[1295]: Accepted publickey for amcvey from [redact] port 50775 ssh2: RSA SHA256:[redact]
Feb 12 09:59:20 myhostname sshd[1295]: pam_unix(sshd:session): session opened for user amcvey by (uid=0)
Feb 12 09:59:20 myhostname systemd-logind[903]: Got message type=method_call sender=:1.14 destination=org.freedesktop.login1 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=CreateSession cookie=2 reply_cookie=0 signature=uusssssussbssa(sv) error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname sshd[1295]: pam_systemd(sshd:session): pam-systemd initializing
Feb 12 09:59:20 myhostname systemd-logind[903]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=GetConnectionUnixUser cookie=43 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname sshd[1295]: pam_systemd(sshd:session): Asking logind to create session: uid=[redact] pid=1295 service=sshd type=tty class=user desktop= seat= vtnr=0 tty= display= remote=yes remote_user= remote_host=10.105.121.110
Feb 12 09:59:20 myhostname systemd-logind[903]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.6 path=n/a interface=n/a member=n/a cookie=15 reply_cookie=43 signature=u error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname sshd[1295]: pam_systemd(sshd:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=GetConnectionUnixProcessID cookie=44 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.6 path=n/a interface=n/a member=n/a cookie=16 reply_cookie=44 signature=u error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: Unable to connect to /run/systemd/userdb/io.systemd.Multiplexer: No such file or directory
Feb 12 09:59:20 myhostname systemd-logind[903]: n/a: varlink: setting state idle-client
Feb 12 09:59:20 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: Sending message: {"method":"io.systemd.UserDatabase.GetUserRecord","parameters":{"uid":198083,"service":"io.systemd.DynamicUser"}}
Feb 12 09:59:20 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state idle-client → awaiting-reply
Feb 12 09:59:20 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: New incoming message: {"error":"io.systemd.UserDatabase.NoRecordFound","parameters":{}}
Feb 12 09:59:20 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state awaiting-reply → processing-reply
Feb 12 09:59:20 myhostname systemd-logind[903]: Got lookup error: io.systemd.UserDatabase.NoRecordFound
Feb 12 09:59:20 myhostname systemd-logind[903]: /run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state processing-reply → idle-client
Feb 12 09:59:20 myhostname systemd-logind[903]: Failed to do shadow lookup for UID [redact], ignoring: No such process
Feb 12 09:59:20 myhostname systemd-logind[903]: Starting services for new user amcvey.
Feb 12 09:59:20 myhostname systemd-logind[903]: Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=45 reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: Got message type=method_return sender=:1.0 destination=:1.6 path=n/a interface=n/a member=n/a cookie=412 reply_cookie=45 signature=o error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=UserNew cookie=46 reply_cookie=0 signature=uo error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartTransientUnit cookie=47 reply_cookie=0 signature=ssa(sv)a(sa(sv)) error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: Got message type=method_return sender=:1.0 destination=:1.6 path=n/a interface=n/a member=n/a cookie=431 reply_cookie=47 signature=o error-name=n/a error-message=n/a
Feb 12 09:59:20 myhostname systemd-logind[903]: New session 4 of user amcvey.

root@ottub2004tst01:/etc# dpkg -l | grep systemd
ii dbus-user-session 1.12.16-2ubuntu2.1 amd64 simple interprocess messaging system (systemd --user integration)
ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64 nss module providing dynamic user and group name resolution
ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64 system and service manager - PAM module
ii libsystemd0:amd64 245.4-4ubuntu3.4 amd64 systemd utility library
ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes
ii python3-systemd 234-3build2 amd64 Python 3 bindings for systemd
ii systemd 245.4-4ubuntu3.4 amd64 system and service manager
ii systemd-sysv 245.4-4ubuntu3.4 amd64 system and service manager - SysV links
ii systemd-timesyncd 245.4-4ubuntu3.4 amd64 minimalistic service to synchronize local time with NTP servers

[Michael Rutter (mjr19)]

I think I am suffering from the same issue.

I have always run without "UsePAM yes" in sshd_config, but I recently tried turning it on in order to get XDG_ variables set correctly and proper systemd sessions for ssh logins.

In 18.04 it worked as expected, but in 20.04 I get

sshd[387766]: pam_systemd(sshd:session): Failed to create session: No such process

in the logs after turning setting debug on pam_systemd.so

and loginctl does not list the session. I am using NIS, but do not have the added complication of Kerberos.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dan Streetman (ddstreet)]

I suspect this is a dup of bug 1916235 (or it a dup of this); have you tried the workaround (shown below) of allowing systemd-logind network access?

$ sudo systemctl edit systemd-logind
(opens an editor, put in the text below and save it, then reboot and retest)

[Service]
RestrictAddressFamilies=AF_INET
IPAddressAllow=any

[Michael Rutter (mjr19)]

A good idea, but it made no difference for me. I even went a little further and tried

[Service]
RestrictAddressFamilies=AF_INET
IPAddressAllow=any
SystemCallFilter=
ProtectSystem=off
CapabilityBoundingSet=

but still no change, even after a reboot. Logins produce the pair of lines

Apr 5 18:42:09 pc2 sshd[1368]: pam_unix(sshd:session): session opened for user mjr19 by (uid=0)
Apr 5 18:42:09 pc2 sshd[1368]: pam_systemd(sshd:session): Failed to create session: No such process

save that if sshd is not run under systemctl, but rather as "sshd -ddd" from the command line, the "failed to create session" line is not logged, either to stderr or syslog. Still no session is created though.

[Andy McVey (andrewmcvey)]

To confirm, this is not a duplicate of bug 1916235. I see none of the associated errors in the logs and the workaround is ineffective.

[Dan Streetman (ddstreet)]

Ok I think we need to see the pam_systemd side of this then; can you add 'systemd.log_level=debug' to the boot params and reboot, and then recreate the failure? There will be a whole lot of debug in the journal, but it should include the pam-side failure.

[Andy McVey (andrewmcvey)]

Below is contents of /var/log/syslog right at the point I press return on entering the password. I've removed the systemd-resolved messages as all they're showing is the response from the kerberos service, which is clean.

Apr 7 12:28:45 myhostname systemd[1]: n/a: New incoming connection.
Apr 7 12:28:45 myhostname systemd[1]: n/a: Connections of user 0: 0 (of 1024 max)
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: setting state idle-server
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: New incoming message: {"method":"io.systemd.UserDatabase.GetMemberships","parameters":{"userName":"amcvey","service":"io.systemd.DynamicUser"},"more":true}
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state idle-server → processing-method-more
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: Sending message: {"error":"io.systemd.UserDatabase.NoRecordFound","parameters":{}}
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state processing-method-more → processed-method
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state processed-method → idle-server
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: Got POLLHUP from socket.
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state idle-server → pending-disconnect
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state pending-disconnect → processing-disconnect
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state processing-disconnect → disconnected
Apr 7 12:28:45 myhostname systemd[1]: n/a: New incoming connection.
Apr 7 12:28:45 myhostname systemd[1]: n/a: Connections of user 0: 0 (of 1024 max)
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: setting state idle-server
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: New incoming message: {"method":"io.systemd.UserDatabase.GetMemberships","parameters":{"userName":"amcvey","service":"io.systemd.DynamicUser"},"more":true}
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state idle-server → processing-method-more
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: Sending message: {"error":"io.systemd.UserDatabase.NoRecordFound","parameters":{}}
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state processing-method-more → processed-method
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state processed-method → idle-server
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: Got POLLHUP from socket.
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state idle-server → pending-disconnect
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state pending-disconnect → processing-disconnect
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: changing state processing-disconnect → disconnected
Apr 7 12:28:45 myhostname systemd[1]: n/a: New incoming connection.
Apr 7 12:28:45 myhostname systemd[1]: n/a: Connections of user 0: 0 (of 1024 max)
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: varlink: setting state idle-server
Apr 7 12:28:45 myhostname systemd[1]: varlink-55: New incoming message: {"method"...

[Dan Streetman (ddstreet)]

First, from re-reading the bug description, it seems like you don't have nis in your nsswitch.conf file? I'm not an expert in NIS config/usage, but I think you need to add that, e.g. at *least*:

passwd: compat nis systemd

you might need to add it to group, shadow, and gshadow as well.

Second, does getent work? If not, that's most likely your problem; e.g.:

$ getent passwd 198083

Third, you could try setting up nscd if you haven't already, which may help if your NIS lookups are slow.

Finally note that this upstream systemd bug appears to match your problem, and the conclusion there was the problem is either a local config issue or NIS bug:
https://github.com/systemd/systemd/issues/12702

[Andy McVey (andrewmcvey)]

Dan, thanks for the comments, appreciate it. In reply:

Using only "compat" in /etc/nsswitch.conf is legitimate and we use it without issue on multiple Linux distributions as well as older Ubuntu releases. It invokes a different behaviour to using "nis", allowing more fine grained control of who can authenticate from the NIS database by appending +user|+netgroup to /etc/passwd. FWIW, replacing "compat" with "nis" and removing the + entries at the end of the passwd file yields the same systemd behaviour. Earlier in testing I tried using sssd, going direct to AD, cutting out NIS entirely. Using sssd also failed to start the systemd user context. I will try that again tomorrow with the debug flags to see that shows up anything new.

getent passwd amcvey responds immediately and correctly, suggesting the underlying calls to getpwnam() are also working correctly. All other NIS accounts are also resolved correctly and without delay.

I don't think using nscd will help much here, the issue is not the response time from the NIS server(s) or the number of calls being made. This also makes me think that the bug you referenced (https://github.com/systemd/systemd/issues/12702) is not the root cause here, as there are performance issues in that use case, which I'm not seeing here at all.

[Bryan Youse (bryouse)]

We are seeing the same issue with essentially the same setup (NIS for accounts with nsswitch in compat mode, Kerberos for authentication).

We see the same pam_systemd debug message when attempting to log in as regular/remote user:
pam_systemd(sshd:session): Failed to create session: No such process

Naturally loginctl doesn't report the session. No /run/user/$UID directory gets created, and additionally, trying to run "systemctl --user" spits out: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set. After manually setting this variable, we see the familiar "Failed to connect to bus: No such file or directory"

Strangely, this problem is not present on some of our slightly older 20.04 VMs in the fleet. The working VMs are using systemd version 245.4-4ubuntu3.2

We noticed this behavior yesterday on 245.4-4ubuntu3.4, and the problem persists having upgraded to 245.4-4ubuntu3.6. This definitely looks like a regression, but I'm not sure which package is at fault or how to debug/pinpoint further.

[Andy McVey (andrewmcvey)]

Just to clarify my earlier comments, I went back and tested using sssd, removing NIS entirely, with AD used as an RFC2307-compliant LDAP back end. I was not able to reproduce the problem, implying that this issue is restricted to NIS only.

[Michael Rutter (mjr19)]

A little more information, after some investigation.

The issue affects xdm logins at the console, as well as remote ssh logins. This also means that audio at the console fails to work, as ACLs for the console's user are not added to the audio devices.

It seem that it can be solved by putting in /etc/systemd/system/systemd-logind.service.d/override.conf

[Service]
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET
IPAddressDeny=
ProtectHostname=no

after which "systemctl daemon-reload" followed by "systemctl daemon-reexec" does nothing useful, but a reboot does cause things to start working. (I don't understand why daemon-reexec differs from rebooting.) Changing the above file is approximately equivalent to "systemctl edit systemd-logind" followed by "systemctl daemon-reload", but, when faced with multiple machines, the file change may be easier to script. Note that the directory probably does not exist.

The need for ProtectHostname=no seems new, and note also that if one speaks IPv6 to one's NIS servers, AF_INET6 may be necessary.

I do not use nscd, which may also solve the issue.

I don't understand Haoke's comment that systemd is not involved.

[Dan Streetman (ddstreet)]

Ok, so it does sound like this and bug 1916235 are the same issue. And this might be 'as designed', since upstream systemd wants systemd-logind to talk to systemd-userdb instead of directly connecting to NIS servers; however Debian (and Ubuntu) disable systemd-userdb.

@rbalint @ahasenack @mbiebl, since Debian/Ubuntu disable systemd-userdb, should we also adjust the systemd-logind RestrictAddressFamilies= restriction (and IPAddressDeny= and/or IPAddressAllow=) to allow networking? I'm not sure why ProtectHostname= would also be needed, but I assume it's related to the tighter restrictions on systemd-logind.

> I don't understand why daemon-reexec differs from rebooting.

daemon-reload and daemon-reexec only affect pid 1; you need to actually (also) restart systemd-logind after making a change to its unit file; reloading/reexecing pid 1 won't change anything about the running systemd-logind.

[Michael Rutter (mjr19)]

Thanks for that. I can confirm that

systemctl daemon-reload; systemctl restart systemd-logind

(in that order) avoids the need for a reboot, and for a couple of my machines I am very grateful for this information.

[Andy McVey (andrewmcvey)]

I can confirm the workaround is good for me too. I don't seem to need the "ProtectHostname=no" option though, and in fact, the workaround in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1916235 is also now working as well. Looking at the test system I used today it's running systemd 245.4-4ubuntu3.2, whereas the version I originally tested was 245.4-4ubuntu3.4. I'll try updating to ...3.6 and see what that does.

[Andy McVey (andrewmcvey)]

Slightly odd behaviour with systemd version 245.4-4ubuntu3.6. In /etc/systemd/system/systemd-logind.service.d/override.conf I have:

[Service]
RestrictAddressFamilies=AF_INET
IPAddressAllow=any

On a cold boot I don't get the user session started:
amcvey@ottub2004tst01:~$ systemctl --user
Failed to connect to bus: No such file or directory

But switching to root, running 'systemctl daemon-reload; systemctl restart systemd-logind' and then logging in again as a user account seems to work. I didn't make any changes to the config files, just restart the systemd components.

If I then add ProtectHostname=no and reboot it seems to allow it to boot from cold without having to run systemctl daemon-reload; systemctl restart systemd-logind again.

[Michael Biebl (mbiebl)]

Am Do., 10. Juni 2021 um 14:50 Uhr schrieb Dan Streetman
<email address hidden>:
>
> Ok, so it does sound like this and bug 1916235 are the same issue. And
> this might be 'as designed', since upstream systemd wants systemd-logind
> to talk to systemd-userdb instead of directly connecting to NIS servers;
> however Debian (and Ubuntu) disable systemd-userdb.
>
> @rbalint @ahasenack @mbiebl, since Debian/Ubuntu disable systemd-userdb,
> should we also adjust the systemd-logind RestrictAddressFamilies=
> restriction (and IPAddressDeny= and/or IPAddressAllow=) to allow
> networking? I'm not sure why ProtectHostname= would also be needed, but
> I assume it's related to the tighter restrictions on systemd-logind.

I think the nis package should ship a drop-in config for
systemd-logind, allowing network access in systemd-logind.
This shouldn't be enabled globally for all users.

As for ldap: If you use the new libpam-ldapd, there should be no
problem, as the network access is delegated to a separate process
(nscld).

[Michael Biebl (mbiebl)]

The relevant upstream bug report afaics is
https://github.com/systemd/systemd/issues/7074

Am Do., 10. Juni 2021 um 20:14 Uhr schrieb Michael Biebl <email address hidden>:
>
> Am Do., 10. Juni 2021 um 14:50 Uhr schrieb Dan Streetman
> <email address hidden>:
> >
> > Ok, so it does sound like this and bug 1916235 are the same issue. And
> > this might be 'as designed', since upstream systemd wants systemd-logind
> > to talk to systemd-userdb instead of directly connecting to NIS servers;
> > however Debian (and Ubuntu) disable systemd-userdb.
> >
> > @rbalint @ahasenack @mbiebl, since Debian/Ubuntu disable systemd-userdb,
> > should we also adjust the systemd-logind RestrictAddressFamilies=
> > restriction (and IPAddressDeny= and/or IPAddressAllow=) to allow
> > networking? I'm not sure why ProtectHostname= would also be needed, but
> > I assume it's related to the tighter restrictions on systemd-logind.
>
> I think the nis package should ship a drop-in config for
> systemd-logind, allowing network access in systemd-logind.
> This shouldn't be enabled globally for all users.
>
> As for ldap: If you use the new libpam-ldapd, there should be no
> problem, as the network access is delegated to a separate process
> (nscld).

[Michael Biebl (mbiebl)]

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625

Am Do., 10. Juni 2021 um 20:23 Uhr schrieb Michael Biebl <email address hidden>:
>
> The relevant upstream bug report afaics is
> https://github.com/systemd/systemd/issues/7074
>
> Am Do., 10. Juni 2021 um 20:14 Uhr schrieb Michael Biebl <email address hidden>:
> >
> > Am Do., 10. Juni 2021 um 14:50 Uhr schrieb Dan Streetman
> > <email address hidden>:
> > >
> > > Ok, so it does sound like this and bug 1916235 are the same issue. And
> > > this might be 'as designed', since upstream systemd wants systemd-logind
> > > to talk to systemd-userdb instead of directly connecting to NIS servers;
> > > however Debian (and Ubuntu) disable systemd-userdb.
> > >
> > > @rbalint @ahasenack @mbiebl, since Debian/Ubuntu disable systemd-userdb,
> > > should we also adjust the systemd-logind RestrictAddressFamilies=
> > > restriction (and IPAddressDeny= and/or IPAddressAllow=) to allow
> > > networking? I'm not sure why ProtectHostname= would also be needed, but
> > > I assume it's related to the tighter restrictions on systemd-logind.
> >
> > I think the nis package should ship a drop-in config for
> > systemd-logind, allowing network access in systemd-logind.
> > This shouldn't be enabled globally for all users.
> >
> > As for ldap: If you use the new libpam-ldapd, there should be no
> > problem, as the network access is delegated to a separate process
> > (nscld).

[Michael Rutter (mjr19)]

I can confirm that installing nscd also solves the problem without needing to fiddle with the systemd-logind restrictions. However, I am no fan of nscd. Caching passwords for ten minutes (its default) causes all sorts of confusion when a user changes his password, or requests a password reset, for the protocol has no ability to indicate when the cache is probably invalid.

[Dan Streetman (ddstreet)]

In order to consolidate discussion around how to best fix this, i opened bug 1934393 and will mark this as a dup of that bug

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.