Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#72967 - [filesystem] [pambase] nsswitch.conf change breaks systemd-homed

Attached to Project: Arch Linux
Opened by Hartmut Malzahn (hwm) - Friday, 10 December 2021, 09:03 GMT
Last edited by Jan Alexander Steffens (heftig) - Friday, 11 February 2022, 23:05 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned   Reopened
Assigned To Jan Alexander Steffens (heftig)
S├ębastien Luttringer (seblu)
David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description:

On one machine, I am using systemd-homed for an encrypted home. The changed entry "shadow: files systemd" in nsswitch.conf breaks login with that id. Logging on using the console asks for the password twice, and remotely logging in using ssh gives the error message "Home of user hwm is currently not active, please log in locally first." because /home/hwm is not decrypted and mounted.

Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

Create a user using homectl, then try to log on by ssh
This task depends upon

Comment by Jan Alexander Steffens (heftig) - Friday, 10 December 2021, 12:59 GMT
The systemd entries are how upstream recommends them (see man nss-systemd). So this could be a systemd upstream bug?
Comment by Hartmut Malzahn (hwm) - Friday, 10 December 2021, 13:22 GMT
It very much looks that way. Thinking about it, it is quite strange that the old entry "shadow: files" works perfectly, even despite being no entry for the user in passwd or shadow - it was created using homectl.
Comment by Jan Alexander Steffens (heftig) - Friday, 10 December 2021, 13:37 GMT
Huh, I think our pam config might be wrong.

Try editing /etc/pam.d/system-auth:

Switch auth unix and systemd_home so that systemd_home is first and has success=2:

-auth [success=2 default=ignore] pam_systemd_home.so
auth [success=1 default=ignore] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail

Add session systemd_home at the start of the session stack:

-session optional pam_systemd_home.so
session required pam_limits.so


Comment by Hartmut Malzahn (hwm) - Friday, 10 December 2021, 13:50 GMT
Yes, that works fine with the new nsswitch.conf now!

Loading...