The title says almost all.

When I am a local user (let's say the normal situation) my session gets a seat assigned.

jlinkels@donald-pc:~$ loginctl 
      3 1000 jlinkels seat0 

However when I authenticate through NIS (which is normal on my network) it does not happen:

jlinkels@donald-pc:~$ loginctl
No sessions.

This is bad in the first place because starting in Debian 10 access permissions for devices like scanners and webcam are added in udev for the local user. The user holding the seat.

I could work around that by assiging pre-Debian 10 group permissions to devices. But it is undesirable because I don't want to edit udev rules for every installation I make. Worse is that TeamViewer 15, which is the first native Linux version, does not run if I don't have a seat assigned.

I have no idea how to tweak systemd, pamd, logind or NIS to assign a seat to my session. This is all completely new for me. (And perhaps another level of complication by systemd)

Kernel: 4.19.0-9-amd64
Debian 10 Buster
KDE5 Plasma

  • I have a guess, but does the situation change if you start nscd.service and re-login? – user1686 Jun 26 at 7:55
  • No I tried it and ot doesn't make any difference. Maybe if I log in first locally, then change /etc/passwd so the next time I use NIS. But since nscd is aware of changes in /etc/passwd it is also unlikely that would work. – Johannes Linkels Jun 26 at 15:43

The most likely cause is that systemd-logind is unable to resolve your user name to UID (or vice versa), because the libnss_nis name lookup module directly makes network RPC calls to your NIS server, while systemd-logind has all network access blocked as a security precaution.

(Other name lookup modules, such as libnss_sss from SSSD, as well as the newer libnss_ldap that comes with nslcd, do not have this problem because they only connect to a local daemon process which handles all network traffic – and caching – centrally.)

There are two ways to get around this problem:

  1. Use SSSD configured with the 'proxy' id_provider. The NIS name lookup module will only need to be loaded by SSSD itself and all other processes will query it over local sockets.

  2. Use systemctl edit --full systemd-logind to disable the network restrictions in systemd-logind, by removing the IPAddressDeny= and RestrictAddressFamilies= options. (And probably SystemCallFilter= as well.)

(I want to list nscd.service as a third way, as it also moves the queries out of the logind process somewhat like SSSD does, but it isn't really meant for that purpose – it's meant to be a caching daemon only and won't prevent fallback to making the NIS requests in-process as before.)

| improve this answer | |
  • user 1686 you definitely know what you are talking about. The error was that systemd-logind network access blocked. Your suggestion (2) worked. Eventually I added IPAddressAllow=my.local.subnet.0/24 and added AF_INET and AF_INET6. This article: wiki.archlinux.org/index.php/…. But I was only able to find that articel after I knew the solution. – Johannes Linkels Jun 26 at 18:51
  • And trying to dig more into the backgrounds, I could not find anywhere ANY documentation on the IPAddressDeny option in systemd-logind. Logically it should be in man login.conf, but it is not mentioned. – Johannes Linkels Jun 26 at 18:53
  • None of those are systemd-logind options – they're options for services under the service manager (systemd-pid1) and are found in 'man systemd.service', 'man systemd.exec', or 'man systemd.resource-control'. Basically the file you're editing via 'systemctl edit' is akin to editing the /etc/init.d scripts. – user1686 Jun 26 at 19:08
  • That really makes it difficult if you edit the option with systemctl edit --full systemd-logind :) But anyway, the option is mentioned in man systemd.resource-control. Thanks again! – Johannes Linkels Jun 26 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.