From 4ab2887d57f9687203eb0ef400cce1cf42dac948 Mon Sep 17 00:00:00 2001 From: David Tardon Date: Tue, 1 Mar 2022 10:59:45 +0100 Subject: [PATCH] pam: do not require a non-expired password for user@.service Without this parameter, we would allow user@ to start if the user has no password (i.e. the password is "locked"). But when the user does have a password, and it is marked as expired, we would refuse to start the service. There are other authentication mechanisms and we should not tie this service to the password state. The documented way to disable an *account* is to call 'chage -E0'. With a disabled account, user@.service will still refuse to start: systemd[16598]: PAM failed: User account has expired systemd[16598]: PAM failed: User account has expired systemd[16598]: user@1005.service: Failed to set up PAM session: Operation not permitted systemd[16598]: user@1005.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation n ot permitted systemd[1]: user@1005.service: Main process exited, code=exited, status=224/PAM systemd[1]: user@1005.service: Failed with result 'exit-code'. systemd[1]: Failed to start user@1005.service. systemd[1]: Stopping user-runtime-dir@1005.service... RHEL-only Resolves: #2059553 --- systemd-user | 1 + 1 file changed, 1 insertion(+) diff --git a/systemd-user b/systemd-user index 2725df9..8607d4f 100644 --- a/systemd-user +++ b/systemd-user @@ -2,6 +2,7 @@ # # Used by systemd --user instances. +account sufficient pam_unix.so no_pass_expiry account include system-auth session required pam_selinux.so close