SUMMARY Attempt to switch users away from a passwordless account (when another session is already running) will result in "locked" screen with a simple passwordless "Unlock" button, and nothing more — i.e. it won't actually switch to a different TTY. STEPS TO REPRODUCE 1. Log in to one account (which has a password set). 2. Start new session and log in to a passwordless account. 3. Click Switch Users button (in Kickoff, users applet or elsewhere). OBSERVED RESULT Screen gets locked for the passwordless account, an "Unlock" button is shown, but sessions won't switch to another TTY. EXPECTED RESULT Should be switching sessions, of course. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE: git master Qt Version: 5.15.5 Kernel Version: 5.19.6-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 970M/PCIe/SSE2 Manufacturer: ASUSTeK COMPUTER INC. Product Name: G752VT System Version: 1.0 ADDITIONAL INFORMATION I get these lines in logs during every such attempt: Sep 10 13:32:06 kscreenlocker_greet[7368]: kf.kirigami: Failed to find a Kirigami platform plugin Sep 10 13:32:06 kscreenlocker_greet[7368]: file:///usr/local/kde/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:265:9: QML StackView: push: nothing to push Sep 10 13:32:06 kscreenlocker_greet[7368]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate() Sep 10 13:32:06 kded5[6011]: ktp-kded-module: "screen-saver-away" presence change request: "away" "" Sep 10 13:32:06 kded5[6011]: ktp-kded-module: plugin queue activation: "away" "" Sep 10 13:32:06 kscreenlocker_greet[7368]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate() Sep 10 13:32:08 kscreenlocker_greet[7368]: pam_systemd_home(kde:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found. Sep 10 13:32:08 kscreenlocker_greet[7368]: pam_unix(kde:auth): user [dude2008] has blank password; authenticated without it Sep 10 13:32:09 kded5[6011]: ktp-kded-module: "screen-saver-away" state change: TelepathyKDEDModulePlugin::Enabled Sep 10 13:32:09 kded5[6011]: ktp-kded-module: plugin queue activation: "unset" ""
Can reproduce. If I log out of the passwordless account, I get deposited at the login screen where it shows the passworded user account with a filled-in password field, but the password field and log in button are disabled. Marking as critical as this requires a hard reboot, so you can lose work in the passworded user account. note: if "passworded" isn't a word, it should be
The way the lock screen is implemented is as two pages. The password page and the nopassword page. Only the former implements user switching. What happens is that the password page loads, PAM sends the all clear, the password page goes "goody we are logged in!" in its onSucceeded slot it then checks if there even was a password prompt (spoiler: there wasn't) and if not it instead goes to the nopassword page. The nopassword page then is basically only a Qt.quit() button. This chain of events causes the switching logic to not even run on the password page and since the nopassword page has no provisions for any of this advanced logic, nothing happens. This seems a bit architecturally defective TBH.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2847
Git commit 7d39865d8ce80380c29806641638fd45e52cbf01 by Harald Sitter. Committed on 11/10/2023 at 13:36. Pushed by sitter into branch 'master'. lockscreen: handle user switching also on nopassword page this is a bit awkward but probably the best we can do without major refactoring. previously we'd miss out on the user switch because that only got handled on the regular login page, when dealing with a password less account we'd get carried away by the succeeded signal to the nopassword page and no user switching page would be on top of the stack view. the page flow has been slightly changed to better fit the use case: - a new function maybeSwitchUser replaces the previous user switcher - nopasswordunlock now **replaces** the pagestack (which is actually what it did anyway because it has no back button) - nopasswordunlock triggers maybeSwitchUser after completion - regular mainview triggers maybeSwitchUser after completion that end result is that in both scenarios we get a working switcher page M +19 -19 lookandfeel/org.kde.breeze/contents/lockscreen/LockScreenUi.qml M +1 -0 lookandfeel/org.kde.breeze/contents/lockscreen/NoPasswordUnlock.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/7d39865d8ce80380c29806641638fd45e52cbf01
Git commit ebc17b15d9f8ad99d6b99ab355a47d0bf18a2b07 by Harald Sitter. Committed on 11/10/2023 at 14:02. Pushed by sitter into branch 'Plasma/5.27'. lockscreen: handle user switching also on nopassword page this is a bit awkward but probably the best we can do without major refactoring. previously we'd miss out on the user switch because that only got handled on the regular login page, when dealing with a password less account we'd get carried away by the succeeded signal to the nopassword page and no user switching page would be on top of the stack view. the page flow has been slightly changed to better fit the use case: - a new function maybeSwitchUser replaces the previous user switcher - nopasswordunlock now **replaces** the pagestack (which is actually what it did anyway because it has no back button) - nopasswordunlock triggers maybeSwitchUser after completion - regular mainview triggers maybeSwitchUser after completion that end result is that in both scenarios we get a working switcher page (cherry picked from commit 7d39865d8ce80380c29806641638fd45e52cbf01) M +19 -19 lookandfeel/org.kde.breeze/contents/lockscreen/LockScreenUi.qml M +1 -0 lookandfeel/org.kde.breeze/contents/lockscreen/NoPasswordUnlock.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/ebc17b15d9f8ad99d6b99ab355a47d0bf18a2b07