You are not logged in.
I'm running Arch and KDE. System is fully updated as of a few hours ago. I have not run into this problem before. A user account cannot change its own password while knowing the current password. Entering the correct current password results in "Authentication failure".
Which config files control this. I would like to restore the stock or default settings. I assume those allow a user to change their own password.
SOLUTION:
It's this dialog: https://userbase.kde.org/System_Settings/User_Manager
This file [/usr/share/polkit-1/actions/org.freedesktop.accounts.policy] contains the following policy:
<action id="org.freedesktop.accounts.change-own-password">
<description>Change your own user password</description>
<message>Authentication is required to change your own user password</message>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
</action>Changing the allow* defaults as per the polkit ref solved the problem.
Last edited by MountainX (2020-11-30 22:21:16)
Offline
Probably the polkit rule for whatever specific tool you're using there to change the password.
Does
passwdwork?
Offline
Yes, passwd works correctly.
The tool I'm using is KDE's systemsettings5. I don't find a polkit rule related to that. There is also not an entry in /etc/pam.d/ that matches that exact name.
Offline
You're looking for stuff in /usr/share/polkit* (requires roo access)
Does it actively ask for the user password?
Is your user in the %wheel group? (check "id")
Offline
Does it actively ask for the user password?
Maybe I didn't explain it well enough, but this is when a KDE user goes into system settings > user management and attempts to change their own password. The dialog then asks them to authenticate, and entering their password is not sufficient to authenticate (due to some policy I haven't found).
Is your user in the %wheel group? (check "id")
I don't believe normal users should be in the wheel group. So the answer is "no". But membership in the wheel group should not be required to allow a user to change their own password when they know their password.
Offline
Yes, but we don't live in a shouldland, do we…?
What I meant by "Does it actively ask for the user password" is whether the password dialog you see asks you for a specific authentication (user or root) because if it requires you to authenticate as root and you issue your user password, KDE might not provide a feature you're looking for, but there's nothing wrong with the behavior. You just enter the wrong password.
Offline
Yes, but we don't live in a shouldland, do we…?
haha. that's good. :-)
What I meant by "Does it actively ask for the user password" is whether the password dialog you see asks you for a specific authentication (user or root) because if it requires you to authenticate as root and you issue your user password, KDE might not provide a feature you're looking for, but there's nothing wrong with the behavior. You just enter the wrong password.
It's this dialog: https://userbase.kde.org/System_Settings/User_Manager
I found the explanation. This file [/usr/share/polkit-1/actions/org.freedesktop.accounts.policy] contains the following policy:
<action id="org.freedesktop.accounts.change-own-password">
<description>Change your own user password</description>
<message>Authentication is required to change your own user password</message>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
</action>Changing those policies should solve my issue. I'm getting ready to test it.
EDIT: tested - works perfectly now.
I guess I know what you will say ("we don't live in shouldland"), but that's a horrible default policy! Why the hell would the default policy be to prevent users from changing their own passwords (when knowing the current password)? Dumb policy.
Last edited by MountainX (2020-11-30 22:18:35)
Offline
Apparently it's because we're stupid.
https://gitlab.freedesktop.org/accounts … /issues/17
We need to enforce this, because otherwise we're allowing the user to bypass password sanity enforcement rules.
Offline
Thanks for that link. Another interesting read!
Offline