teknoraver / rpms / systemd

Forked from rpms/systemd 2 months ago
Clone
Blob Blame History Raw
From a677e477ef541d172ede2a5bd728a4ff1ffb312d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
Date: Tue, 1 Jun 2021 16:17:16 +0200
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 not 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...

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1961746.

(cherry picked from commit 71889176e4372b443018584c3520c1ff3efe2711)

Resolves: #1961746
---
 src/login/systemd-user.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/login/systemd-user.m4 b/src/login/systemd-user.m4
index 4f85b4b7fe..20c8999331 100644
--- a/src/login/systemd-user.m4
+++ b/src/login/systemd-user.m4
@@ -2,7 +2,7 @@
 #
 # Used by systemd --user instances.
 
-account required pam_unix.so
+account sufficient pam_unix.so no_pass_expiry
 m4_ifdef(`HAVE_SELINUX',
 session required pam_selinux.so close
 session required pam_selinux.so nottys open