Since the upgrade of opensuse to KDE4 4.10 the automatic unlocking has stopped working. Before, I used to use a little application called blueproximity which would connect to my mobile phones bluetooth and, when a certain distance away, lock the screen, and when I would come close enough again, the screen would be unlocked without my intervention.
I also use a script that would lock my screen, after a few minutes of after an hour of inactivity, depending if I was at home or away, and would among others lock the screen. This would even work if the screensaver was already active but not locked.

The used commands to unlock was

Code: Select all

qdbus org.freedesktop.ScreenSaver /ScreenSaver SetActive false

and to be able to lock when the screensaver was active I would first issue

Code: Select all

qdbus org.freedesktop.ScreenSaver /ScreenSaver SimulateUserActivity

before sending the dbus command to lock.

Both have ceased to work, when the screensaver is already active it is not possible to lock it, and when it is locked it will not unlock without me typing the password.

Did these features just disappear or is there something that changed so it would be possible to use it again? It would be very nice if this could work again!

Please check the API offered by KSMServer, where this functionality was moved. It is possible that the org.freedesktop.ScreenSaver registration was forgotten when the functionality was moved.

Code: Select all

qdbus org.kde.ksmserver /ScreenSaver

The behavior is the same, if I run

Code: Select all

qdbus org.kde.ksmserver /ScreenSaver Lock ; sleep 5 ; qdbus org.kde.ksmserver /ScreenSaver SetActive false

in konsole, I would expect it to remove the lock and the screensaver after 5 seconds (as used to be before), but I still have to enter my password.
Or is there another way to accomplish this?

It would appear that (likely for security reasons) being able to bypass providing your password has been removed, at least as far as I can tell.
Internally, there is a Unlock() function much like the Lock() one, but it is not being exported via D-Bus.

I can understand the security issue, but on the other hand it is something started by the same user that locked the screen, so the security implications may be low?

This Unlock() function that is not being exported via D-Bus, how then can it be accessed?

Unfortunately the security implications still exist, as many programs (which may be malicious) are virtually always running as the user who is logged in, and whose session is protected. These include web browsers and their plugins, which are effectively executing arbitrary code from an outside source - and which therefore may be compromised.

The Unlock function can only be accessed by code running as part of KSMServer, which is the process responsible for managing the session. If it is killed (or exits) then your session will immediately end. There is no other method to access it to the best of my knowledge.

One possible workaround is to put your own "kscreenlocker" executable in place, which will accept a D-Bus call (or some other form of command) and will then exit with a status code of "0" which will indicate to KSMServer that the correct password was provided (at which point, it will unlock the session).

KScreenLocker can usually be found at "$PREFIX/lib64/kde4/libexec/kscreenlocker" or "$PREFIX/lib/kde4/libexec/kscreenlocker". KDE will not search other paths for "libexec" executables however.

Ok, I understand the reasoning and will try that "kscreenlocker" stuff. Still one part remains which I don't see has something to do with security: when the screensaver is already active but not locked, there is no way to lock it. This also used to be different and would allow a script to lock the screen after a certain time, even if the screensaver was already running (but not locked). Would be nice if there was a solution for that, but maybe also accessing kscreenlocker directly solves this.

And connected to this all which to me has security implications is that since KDE 4.10 the default screensaver from KDE is one that shows a dialog asking for the user's password with the possibility to change user. This shown always, even if the screen is not locked. In the beginning I thought my screen was locked, but the discovered it wasn't at all, giving a false sense of security. I don't know if that is a bug and should be reported, but would like to mention it here.

dutchkind wrote:Still one part remains which I don't see has something to do with security: when the screensaver is already active but not locked, there is no way to lock it. This also used to be different and would allow a script to lock the screen after a certain time, even if the screensaver was already running (but not locked). Would be nice if there was a solution for that, but maybe also accessing kscreenlocker directly solves this.

This is something that should be solved in 4.10.2 - are you running an older version?

dutchkind wrote:And connected to this all which to me has security implications is that since KDE 4.10 the default screensaver from KDE is one that shows a dialog asking for the user's password with the possibility to change user. This shown always, even if the screen is not locked. In the beginning I thought my screen was locked, but the discovered it wasn't at all, giving a false sense of security. I don't know if that is a bug and should be reported, but would like to mention it here.

This is a known bug - https://bugs.kde.org/show_bug.cgi?id=315442 - and one I'm addressing right now.

Ideally you could use a bluetooth PAM module for authentication, but I'm not sure whether one exists. I think it would just be a matter of editing /etc/pam.d configuration if there were a suitable module.

There's also the kdm kgreet plugins that are used by the screenlocker (which provide e.g. the actual password entry fields - there's one for face authentication somewhere, I think), but I don't think they are relevant here. Even if they were, I don't think it's yet clear whether they are going to remain once kdm is removed or whether they will be replaced with something shared with lightdm etc.

Another possible method of implementation would be for the screen locker to support system wide plugins which could unlock the session if their conditions are met. This would be useful for bluetooth proximity as well as a similar implementation using dongles, etc where the device itself does not handle authentication.

This is something that should be solved in 4.10.2 - are you running an older version?

That is the version I am running. But locking when the screensaver is already active doesn't seem to work. Is that with all screensavers, I am using the "Desktopwidgets" but before I have tried the Simple locker (translated from Dutch). The blank screen one I used to use before isn't working anymore.

dutchkind wrote:

This is something that should be solved in 4.10.2 - are you running an older version?

That is the version I am running. But locking when the screensaver is already active doesn't seem to work. Is that with all screensavers, I am using the "Desktopwidgets" but before I have tried the Simple locker (translated from Dutch). The blank screen one I used to use before isn't working anymore.

Can you describe this in more detail: what are your "Screen Locker Settings"; how do you start the screenlocker; what do you do to lock it once it's active; what happens?