Version: (using KDE 4.1.2) OS: Linux Installed from: Debian testing/unstable Packages I have a kde 4.1.2 running on my debian SID. My user have no password at all. I mean this is my /etc/shadow : seb:*:14075:0:99999:7::: I configured kdm so it will allow this user to login without password. But when my son use my computer he create a new session. This will lock my own session without a way to unlock. (obviously enough : this user have no password)
also, if you have two users logged in at the same time and switch between the two sessions, the leaving session is sometimes getting locked, sometimes not. Sounds like a race condition to me. This bug was introduced somewhere around early kde 3.5.x and is still present in 4.2_rc1
It would be useful to have two different options in KDE4: 'Lock current and start new session' - to start a new session locking the current one 'Start new session' - to start a new session without locking the current one as it is in KDE3.5
*** This bug has been confirmed by popular vote. ***
I had a similar problem. As I see it, there are two cases. The first is a bug, the second merely bothersome: * If a user has a password and kdm is set to let the user login without a password, then unlocking the session requires a password. This doesn't work when the user has forgotten the password or the password is set to be too strong to remember. * If a user has an empty password (i.e. set as empty in /etc/password or /etc/shadow) then the password dialog appears and accepts an empty password and unlocks the session. Ideally it would not appear at all, but I appreciate that this may be hard to achieve.
I'm not sure whether there is anything which could be done at all. A few considerations: * the lock screen does not know how kdm is configured and it is nowadays also rather irrelevant as kdm is not used in Plasma 5 any more. * the lock screen can be disabled through kiosk framework. * the lock screen is not able to know whether an "empty" password is used. It would need to be able to read the /etc/shadow and of course is not allowed to do that (just a user process after all). An "empty" password is just a password like any else and of course there should be a password check A difference is the disabled password from the initial comment. Here we need to consider that again the lock screen cannot know that the password is disabled. Now to my understanding there is no concept of disabled passwords. A "*" is just a possible key which can never be a hash. So whatever is entered as a password cannot match the stored password making it impossible to unlock. This is actually correct behavior. I assume in this situation it's also not possible to lock in to a TTY.
Git commit 0e16e4e421ba692e16fd8d0c1d256c7c193a01cd by Martin Gräßlin. Committed on 10/02/2015 at 10:49. Pushed by graesslin into branch 'master'. [screenlocker] Perform KAuthorized check for org.freedesktop.ScreenSaver.Lock The lock screen has an authorized action "lock_screen" which is honored for the global shortcut. The authorized action might disallow the user to lock the screen, so this should also be honored for other ways the user might lock the screen, e.g. through the DBus interface. Idle timeout is not verified through the KAuthorized action as this can be restricted seperately. REVIEW: 122509 M +4 -0 ksmserver/screenlocker/interface.cpp http://commits.kde.org/plasma-workspace/0e16e4e421ba692e16fd8d0c1d256c7c193a01cd
With the commit from comment #6 I consider this as a good enough solution. Through the kiosk framework it's possible to disable the screen locking via global shortcut, via dbus and the idle timeout, etc. This means that an admin is able to also configure the system in a way that it doesn't lock at all. Nevertheless it's still possible to explicitly lock the session using logind. This change will be available in Plasma 5.3.