]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
pam: do not require a non-expired password for user@.service
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Tue, 1 Jun 2021 14:17:16 +0000 (16:17 +0200)
committerLennart Poettering <lennart@poettering.net>
Tue, 1 Jun 2021 17:27:25 +0000 (19:27 +0200)
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.

src/login/systemd-user.in

index 343aec4a01bc8c8c6bb1f7463e64dc498755af60..19e649bbe95aac4e67ccbfa1c1049348935058e2 100644 (file)
@@ -5,7 +5,7 @@
 {% if ENABLE_HOMED %}
 -account sufficient pam_systemd_home.so
 {% endif %}
-account sufficient pam_unix.so
+account sufficient pam_unix.so no_pass_expiry
 account required pam_permit.so
 
 {% if HAVE_SELINUX %}