[ I honestly wonder why this was not reported yet, but I have checked for duplicates very thoroughly. ] KDM's KCM had an option to auto-login as a certain user on boot, and it had an additional option to lock the desktop as part of the auto-login. The benefit is that a single-user machine can be booted into the desktop without any password prompts inbetween (as in: I can boot my system, go get a coffee and come back to a fully loaded desktop), while still being secured from unauthorized physical access. The implementation in KDM would set the environment variable DESKTOP_LOCKED to "yes" in the session, and /usr/bin/startkde would recognize this variable and pass the --lockscreen option to ksmserver. This mechanism still works on the startkde/ksmserver side, as can be witnessed from the workarounds described in https://github.com/sddm/sddm/issues/306 As can also be seen from the link above, SDDM has said that they will not implement such desktop-specific features. I therefore request to have this feature implemented in startkde or ksmserver itself. A useful place to put the configuration UI would be the "screenlocker" KCM. Since the full workflow requires additional configuration in the display manager, I recommend to add a note to this new checkbox saying that "This is useful when your display manager is configured to login to your user automatically on boot" (or similar). Reproducible: Always
Created attachment 105040 [details] KDE4 auto login window I agree completely with Stefan request. I use my pc during conference or school lessons. While waiting for complete boot I can use use my time for introducing subject or answer question, leaving pc unattended. But only if it lock after boot. Please restore this option we had in KDE4 (see attachment). I'm a bit surprised that after one year this bug is still unconfirmed.
I require this ability as well, and fully support this request! I've always used auto-login in the past, but set it to lock the screen after logging me in. However I recently switched from KDM to SDDM, and found that this option no longer exists. Now I have to disable auto-login because my system has no protection with it!
Erm ... without a hard-drive encryption requesting a lockscreen-password is only a little distraction on the way to capture your system. Especially on a mobile device, that may get lost/stolen. But if you already typed one password, it's tedious to type another password later on. Of course the hard-drive password comes very early on, so you'll still have to wait for your autostart programs to be fully loaded. As a works-for-me I'd like to suggest instead suspending your system to RAM (or if working on your hardware: to disk) Yes I admit, on suspend2RAM there is still a little chance of extracting the password from memory, but it's a lot more complicated than simply accessing an unencrypted hard-drive.
(In reply to Holger from comment #3) > Erm ... without a hard-drive encryption requesting a lockscreen-password is > only a little distraction on the way to capture your system. Especially on a > mobile device, that may get lost/stolen. KDE in mobile device with autostart ?????? > But if you already typed one > password, it's tedious to type another password later on. Of course the > hard-drive password comes very early on, so you'll still have to wait for > your autostart programs to be fully loaded. > > As a works-for-me I'd like to suggest instead suspending your system to RAM > (or if working on your hardware: to disk) Suspend to RAM just after having switched on ? > > Yes I admit, on suspend2RAM there is still a little chance of extracting the > password from memory, but it's a lot more complicated than simply accessing > an unencrypted hard-drive. Encrypted hard drive? May be my english knowledge is quite low but I don't see any relation with this bug.
(In reply to Giorgio from comment #4) > KDE in mobile device with autostart ?????? "mobile" in sense of "portable" as: netbook, notebook, laptop > Suspend to RAM just after having switched on ? No, not necessarily. I meant you to prepare for your presentation by opening and arranging all needed programs at home, suspend your device and wake it up the moment you need it. Waking up is quite fast and you can make it query for the password. > Encrypted hard drive? > > May be my english knowledge is quite low but I don't see any relation with > this bug. Hard-drive encryption also requires a password. People likely dislike entering first the hard-drive password and second the login password, so auto-login without password is perfectly sensible if you are using hard-drive encryption. On the other hand, if you don't use hard-drive encryption, the requested feature of auto-login + locked screen provides a false semblance of security, while the device can easily be compromised. In short: - the original request is a security anti-feature - suspend2RAM will hopefully be an acceptable workaround (security-wise as well as usability-wise)
(In reply to Holger from comment #3) > Erm ... without a hard-drive encryption requesting a lockscreen-password is > only a little distraction on the way to capture your system. Especially on a > mobile device, that may get lost/stolen. Could you please elaborate on why this is not secure? It is not clear to me. Thanks.
(In reply to Claus Appel from comment #6) > Could you please elaborate on why this is not secure? It is not clear to me. Sure. An unencrypted HDD can either be physically extracted and read / modified in another PC, that is running it's own operating system. To that other computer everything on your HDD is just data, no restrictions apply. The second even easier possibility is, to boot your device from a USB-Stick, in case you didn't deny this in the BIOS. So the foreign OS is running directly on your hardware and considers your HDD as plain data. You can copy *anything* you like, modify it, destroy it. You could leave a backdoor, change root passwords or create new accounts with root privileges. You get *full* control over every bit of data written on that disk. Encryption will protect you: Nobody can read your data and they cannot modify it or create backdoors. Sure, they can still destroy everything. Encryption does not replace a regular backup. At your desktop at home you usually tolerate this kind of thread. You rely on the security of your house, though an adversary may intrude without you noticing (got a cleaning lady?). On the other hand a laptop staying behind in a classroom with 30 bored pupils, while you visit the bathroom ... I wouldn't take the risk. A lock screen alone is only a minor deterrent like a sign to plead you, not to tread on the grass. Encryption can be a nasty fence with barbwire to keep the evil outside.
The screen locker you activate on demand isn't encrypted either. I don't see why this is relevant to auto-lock on startup: Your computer is as secure with auto-lock as it is when you leave it running after you've manually locked it.
(In reply to Holger from comment #7) > (In reply to Claus Appel from comment #6) > > Could you please elaborate on why this is not secure? It is not clear to me. > > Sure. An unencrypted HDD can either be physically extracted and read / > modified in another PC, that is running it's own operating system. To that > other computer everything on your HDD is just data, no restrictions apply. All right, that makes sense. But does this have anything to do with "autologin-and-lock-screen"? Is it MORE secure to demand password BEFORE logging in the user than it is to demand password AFTER logging in the user? If not, then this - while good advice - does not have anything to do with this bug report, IMO.
(In reply to Mircea Kitsune from comment #8) > The screen locker you activate on demand isn't encrypted either. I don't see > why this is relevant to auto-lock on startup: Your computer is as secure > with auto-lock as it is when you leave it running after you've manually > locked it. Bad enough, you can leave the drivers seat while the engine is still running. But this request is like starting the engine on remote control. I brought up the hdd encryptionm, as I see it as an integral part of the suggested suspend2disk work-around. Why sacrifice security, if you could have both, 1. security and 2. the requested comfort of booting your system to a ready state, waking it up from hibernate? Well, not my decision anyway, so let's wait what the kscreenlocker maintainer thinks on the topic.
(In reply to Holger from comment #10) > so let's wait what the kscreenlocker maintainer thinks on the topic. Does it exist? Bug has been opened more than FOUR ! years ago and I don't see a single answer from KDE maintainers. (In reply to Holger from comment #5) > (In reply to Giorgio from comment #4) > > KDE in mobile device with autostart ?????? > > "mobile" in sense of "portable" as: netbook, notebook, laptop > > > Suspend to RAM just after having switched on ? > > No, not necessarily. I meant you to prepare for your presentation by opening > and arranging all needed programs at home, suspend your device and wake it > up the moment you need it. Waking up is quite fast and you can make it query > for the password. > > > Encrypted hard drive? > > > > May be my english knowledge is quite low but I don't see any relation with > > this bug. > > Hard-drive encryption also requires a password. People likely dislike > entering first the hard-drive password and second the login password, so > auto-login without password is perfectly sensible if you are using > hard-drive encryption. On the other hand, if you don't use hard-drive > encryption, the requested feature of auto-login + locked screen provides a > false semblance of security, while the device can easily be compromised. > > In short: > - the original request is a security anti-feature > - suspend2RAM will hopefully be an acceptable workaround (security-wise as > well as usability-wise)
(In reply to Holger from comment #5) > I meant you to prepare for your presentation by opening > and arranging all needed programs at home, suspend your device and wake it > up the moment you need it. Waking up is quite fast and you can make it query > for the password. I use frequently my laptop in school classroom and I have to answer to student's question then I can't arrange at home what I need. > Hard-drive encryption also requires a password. People likely dislike > entering first the hard-drive password and second the login password, so > auto-login without password is perfectly sensible if you are using > hard-drive encryption. On the other hand, if you don't use hard-drive > encryption, the requested feature of auto-login + locked screen provides a > false semblance of security, while the device can easily be compromised. This procedure seems more secure than lock screen but is much more than I need and more complicated, > In short: > - the original request is a security anti-feature I don't see why, If one know the level of security. > - suspend2RAM will hopefully be an acceptable workaround (security-wise as > well as usability-wise) But sure more complicated. Not a good trade-off for any user.
(In reply to Giorgio from comment #11) > (In reply to Holger from comment #10) > > so let's wait what the kscreenlocker maintainer thinks on the topic. > Does it exist? > Bug has been opened more than FOUR ! years ago and I don't see a single > answer from KDE maintainers. amazing
*** Bug 452442 has been marked as a duplicate of this bug. ***