mirror of
https://github.com/systemd/systemd.git
synced 2025-02-10 17:57:40 +03:00
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.
This commit is contained in:
parent
fedfd21a1f
commit
71889176e4
@ -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 %}
|
||||
|
Loading…
x
Reference in New Issue
Block a user