Description of problem: I have been testing various login and user creation options in KDE lately and realized that it is not possible to expire a password for the user and force them to renew the password upon the next login in sddm as it is possible in gdm. Several scenarios: 1. I use the Users module to create a new user in KDE and choose a password which results in a user that can log in normally via sddm and on console. 2. I use the Users module to create a new user in KDE and do not add password which result in a user that cannot log in via sddm nor the console. 3. I create a user without password using "useradd", in this case I cannot log into the system at all. 4. When I expire the password using "passwd -e" or "chage -d 0", I cannot log into the system using sddm, but I still can log on console and I am asked to change my password. Scenarios 2 and 3 are expected behaviours, but not scenario 4. In GDM, scenario 4 allows me to log in with my previous password and forces me to change it to a new password, similarly to the console behavior. In Gnome, there is also a 5th option, I can create a user without a password and the password is set upon the first login by the user -> this behaviour I could not reproduce using CLI commands or the Users application in KDE Version-Release number of selected component (if applicable): Fedora 31 and Fedora 32 (at least), so this is not a regression. How reproducible: Always Steps to Reproduce: See different scenarios above. Actual results: When the password has (been) expired, the user cannot use sddm to log onto the system. Expected results: Sddm should be able to handle scenario 4.
Update: The situation in scenario 5 can be achieved by using the following commands: 1. useradd test 2. passwd -d test 3. chage -d 0 test Creating the user in this way results in the following situation: 1. With GDM, the user is asked to create a password upon the next login. 2. With console, the user cannot login because empty password is not accepted. 3. With SDDM, the user cannot login because empty password is not accepted. You cannot create a user like this when using KDE GUI tools - Users, you can create them on CLI though.
Proposed as a Blocker and Freeze Exception for 32-final by Fedora user lruzicka using the blocker tracking app because: Expected installed system boot behavior A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. I am proposing this, even if this criterion is fulfilled per se, i.e. you can log into the system using the username and password created during the installation, but you cannot log onto the system when the password is expired (which is a plausible reason on some systems) using the KDE mechanisms. That means, if you are a user (and not admin) of a KDE only machine, you do not have a chance to log into the system and change your expired password.
Pretty sure this is simply an unimplemented feature for ssdm. -1 blocker from me (mostly for practical reasons)
Is this a new issue in Fedora 32 or has it always been like this?
Confirmed, https://github.com/sddm/sddm/issues/716 (it's not new, always been)
According to the link you provided, it seems that other people have concerns, too. I think this feature should be implemented, especially on one of the main Fedora desktops.
Besides, I believe that it, at least, should provide a decent error message saying what the problem really is.
Discussed during the 2020-04-06 blocker review meeting: [0] The decision to classify this bug as a "RejectedBlocker" was made as this is not a clear criteria violation. at best it's a conditional violation of the 'log in/out' criterion, it is not a regression but an unimplemented feature upstream, so we don't think it is significant enough to constitute a blocker. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-06/f32-blocker-review.2020-04-06-16.00.txt
Discussed during the 2020-04-06 blocker review meeting: [0] The decision to classify this bug as a "RejectedFreezeException" was made as fixing this seems to require implementing a missing feature in SDDM, which would be a very significant change and too disruptive to risk during a freeze. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-06/f32-blocker-review.2020-04-06-16.00.txt
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.