Polkit 0.115 on KDE Neon 22.04: Should expired passwords trigger a forced password change during privilege escalation?
0 reputation · 10 Aug 2023, 19:16 UTC
0 reputation · 10 Aug 2023, 19:16 UTC
Determine the correct handling of expired root passwords during privilege escalation on KDE Neon 22.04 LTS, which ships polkit 0.115 and relies on systemd‑logind for session expiration.
Polkit 0.115 introduces a stricter default rule set that requires explicit authorization for any elevation. When a user’s password reaches the expiry date, systemd‑logind marks the session as expired, and PAM prevents further authentication until the password is updated. However, the default polkit configuration does not automatically prompt for a password change; the user must manually trigger a renewal via the KDE Wallet or Konversation settings. The interaction between polkit’s auth_admin_keep action and the expired‑credential state is documented but incomplete.
Should polkit automatically present a “force‑password‑change” dialog when a user with an expired password attempts an elevation, or should the request simply be denied until the user changes the password through a separate mechanism?
auth_admin_keep action when the user’s password is expired?32275 reputation · 10 Aug 2023, 22:20 UTC
Polkit should not automatically present a "force-password-change" dialog during privilege escalation; the request should be denied until the password is changed via a separate mechanism. Polkit is an authorization framework, not an authentication manager, and its GUI agents are generally not designed to handle the multi-step interactive conversation required by PAM for password renewal.
The behavior is governed by the separation of concerns between Polkit and PAM (Pluggable Authentication Modules):
pam_unix.so detect password expiration. When a password has expired, PAM returns a specific status indicating that a password change is required before authentication can succeed.The auth_admin_keep action relates to the caching of authorization (how long a user remains "authorized" without re-entering a password), but it cannot override the underlying PAM requirement for valid, non-expired credentials.
To verify how your specific installation of KDE Neon 22.04 handles this state, you can use the following scoped commands:
testuser with an actual account):
sudo chage -d 0 testuserpkexec) and observe if the agent provides a specific error or a generic "Authentication Failed" message.journalctl -u polkit | grep -i "pam"To determine if a custom fallback is viable, please provide the contents of /etc/pam.d/polkit-1. This will confirm if any non-standard PAM modules are intercepting the authentication flow before it reaches the Polkit agent.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 11 Aug 2023, 06:26 UTC
Polkit 0.115 never sees an expired‑credential state because PAM’s account stack rejects the authentication attempt first. When pam_unix.so (in the account phase) detects an expired password it returns PAM_AUTHTOK_EXPIRED, which the polkit agent treats as a plain authentication failure. The auth_admin_keep cache is only consulted after a successful PAM conversation, so no cached authorization can be reused.
KDE Neon 22.04’s polkit-kde-agent-1 (5.24.x) does not implement the Response2 signal that would allow a custom “change password” challenge, and the default /etc/pam.d/polkit-1 stack contains no fallback to a password‑change helper. The only supported path is a full re‑login (TTY, SSH, or display manager) where PAM’s password‑change flow runs, or an explicit passwd/chage call before attempting elevation.
Quick verification: sudo -k; sudo true with an expired‑password account yields an immediate denial and no password‑change prompt.