https://bugs.kde.org/show_bug.cgi?id=505239
Bug ID: 505239
Summary: [BUG] Password prompt resets after opening with high
YESCRYPT_COST_FACTOR
Classification: Plasma
Product: policykit-kde-agent-1
Version First 6.3.5
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: danielrh+kdeb...@proton.me
CC: d...@kde.org, jgrul...@redhat.com, jrez...@redhat.com
Target Milestone: ---
Created attachment 182046
--> https://bugs.kde.org/attachment.cgi?id=182046&action=edit
Screen recording demonstrating the bug
SUMMARY
On an account with password hash method set to yescrypt with
YESCRYPT_COST_FACTOR set to 11, a couple seconds after a GUI password prompt
window pops up, the prompt window "shakes" as if an incorrect password was
entered and deletes any entered characters. It does *not* display an
"Authentication failure" alert after this, and entering the password after this
works normally.
STEPS TO REPRODUCE
1. Log in to a graphical KDE session with a user in the `wheel` group.
2. Edit `/etc/login.defs` to set `YESCRYPT_COST_FACTOR 11`.
3. Change the user password (so it's re-hashed with the new settings).
4. Run `pkexec` or `run0` in a terminal.
5. Immediately enter a few random characters when the password prompt opens.
6. Wait a few seconds.
OBSERVED RESULT
The password prompt window unexpectedly shakes and resets after a couple
seconds. The attached screen recording shows this.
EXPECTED RESULT
The password authentication window shouldn't unexpectedly reset itself.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora Kinoite version 42.20250605.0 (tested in a freshly
installed VM with no other changes after installation and updating)
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Polkit version: 126
ADDITIONAL INFORMATION
I tested this with various yescrypt cost factors, and this bug only seems to
occur with YESCRYPT_COST_FACTOR >= 9. The delay between the password prompt
opening and resetting is shorter the smaller the cost factor is, and with cost
factor 9 it's usually just a fraction of a second. This seems like it must be a
race condition of some sort.
Also, this may or may not be related, and is more subtle, but I think the
password prompt is also slower to appear with a higher yescrypt cost factor.
This seems strange to me, since the hashing method should only affect what
needs to be done *after* the password is entered, right?
The system logs don't seem to show anything relevant: `journalctl -u
polkit.service` shows nothing except polkit.service starting successfully when
the system was booted.
I'm unsure whether this is a bug in policykit-kde-agent-1 or in Polkit itself,
so I've also reported this to Polkit:
https://github.com/polkit-org/polkit/issues/569
--
You are receiving this mail because:
You are watching all bug changes.
