It's not pretty, but as an interim solution until this is fixed, you can do something like this:

qdbus | grep kscreenlocker | sed 's/org.kde.//' | xargs kquitapp

From looking into the last command, the challenge is that the new screenlocker in 4.10 includes the PID for its instance.

In other words, each time it is launched it seems to me that it will be a new name to kill or call quit on using qdbus:
org.kde.kscreenlocker_greet-{some PID}

I found the following successful as well to unlock the system using blueproximity:

qdbus | grep kscreenlocker_greet | xargs -I qdbus {} /MainApplication quit

Similar to the old way, just having a need to find the name itself.  Shane's version just as well may work.

(In reply to comment #2)
> From looking into the last command, the challenge is that the new
> screenlocker in 4.10 includes the PID for its instance.
> 
> In other words, each time it is launched it seems to me that it will be a
> new name to kill or call quit on using qdbus:
> org.kde.kscreenlocker_greet-{some PID}
> 
> I found the following successful as well to unlock the system using
> blueproximity:
> 
> qdbus | grep kscreenlocker_greet | xargs -I qdbus {} /MainApplication quit
> 
> Similar to the old way, just having a need to find the name itself.  Shane's
> version just as well may work.

* Sorry I forgot to include the following for xargs:

qdbus | grep kscreenlocker_greet | xargs -I {} qdbus {} /MainApplication quit

I have a separate machine that I use synergy to control and was using a script to unlock the screensaver using the SetActive/SimulateUserActivity method.  This also broke for me but Shane McCormack's solution worked for me as a workaround.  I just used a different variant but same result.

    qdbus | perl -ne 'qx/kquitapp $1/ if /(kscreenlocker_greet-\d+)/'

I hope this gets fixed soon because the old method was much cleaner in my opinion.

I can also confirm this.
KDE 4.11.5.

So, seems that the commit in question is a7d599fda6c6e2798c444556f62c46f6512f79c8.

The commit message states that “Most parts are not yet implemented as it either does not make sense (e.g. setActive(false)) …”. I think, that's arguable.

The correct way to implement custom unlock functionality is by providing a custom greeter theme which does that (c.f. Plasma Active lock screen). That it is possible to end kscreenlocker_greet is clearly a bug.

Some apps don't need custom greeter theme, they must do unlock action on any lock screen or theme. For example, unlocking via bluetooth proximity - this app must do unlock action for any lock screen, because it not provide new greeter theme, it provide comfortable way to unlocking computer. 
How apps like this must do unlock screen action if kscreenlocker_greet is clearly a bug?

> Some apps don't need custom greeter theme, they must do unlock action on any
> lock screen or theme. For example, unlocking via bluetooth proximity - this
> app must do unlock action for any lock screen, because it not provide new
> greeter theme, it provide comfortable way to unlocking computer.
> How apps like this must do unlock screen action if kscreenlocker_greet is
> clearly a bug?

What about having a PAM module? kscreenlocker_greet is not doing 
authentication, it delegates this to PAM, thus any authentication mechanism 
needs to go into PAM.

Thanks for quick answer. As I understand, PAM modules do the authentication process on user login, so for example user on login can skip password entering. But I don't understand how we can via PAM module do unlock screen action.

Can you describe or provide link to some example how PAM module can do the action "Unlock KDE screen and unload screensaver"?

That's, actually, what I was suggesting on the reviewboard.

You can have a PAM module, that will accept authentication based on your bluetooth device proximity (or USB drive being plugged in, etc). So this way, when you hit Enter on your lockscreen, as currently lockscreen checks auth through PAM, if your PAM modules is installed and properly configured, it will let you in. So, you just have to hit Enter, without entering your password.

The next step is adding DBus interface to screenlocker, that will provide a method, basically, HitEnter.

So, this is how it works: then your token becomes available, someone (e.g. udev in case of usb drive, or bluetooth daemon in case of BT token) calls this method, and Enter is automatically pushed. And since the token is here, your PAM module will let you in.

> So, this is how it works: then your token becomes available, someone (e.g.
> udev in case of usb drive, or bluetooth daemon in case of BT token) calls
> this method, and Enter is automatically pushed. And since the token is
> here, your PAM module will let you in.

this is something which might even be done by the greeter itself. By e.g. 
mapping a list of devices which are allowed to trigger the authentication. I'd 
prefer to have this properly integrated in the locker than exposing internal 
details through DBus.

(In reply to comment #12)
> exposing internal details through DBus.

I can't agree that asking the locker to try to check authentication is an internal detail.
In this case making the user enter his password and click “unlock” is also forcing him to use an internal detail of the locker.

I just got an even better idea. Using this, we can make sense of `SetActive(false)`. That is, we just make `SetActive(false)` “hit enter”. This way, maybe other lockers will also adopt this notion of “trying to deactivate the locker”.
Integrating this functionality into the greeter looks worse simply because it's not that flexible.

> I can't agree that asking the locker to try to check authentication is an
> internal detail.

Yes it is, as the locker doesn't check the authentication, it's the greeter. 
But the greeter should not be exposed to DBus.

FYI: I have locally a variant which supports logind. This means if logind 
emits the Unlock signal, the screenlocker will unlock. That should be a 
sufficient solution for this bug report.

(In reply to comment #14)
> FYI: I have locally a variant which supports logind.

Review Request for logind integration

Hi,

I strongly  disagree that the ability to stop the screensaver programatically should be considered to be a bug.

This functionality has existed since KDE3 days, (`dcop kdesktop KScreensaverIface quit`) then more recently as `qdbus org.freedesktop.ScreenSaver /ScreenSaver SetActive False` (http://lists.freedesktop.org/archives/xdg/2007-March/009187.html) and then in 4.10 the new screensaver/greeter was introduced which removed the nice and standard way of doing it (Other screensavers for example gnome-screensaver still allow SetActive false on org.freedesktop.ScreenSaver last time I checked) but at least still allowed unlocked with a bit of fiddling.

My current use for this functionality is a script that is activated by udev when my phone is connected to the computer (via a desktop dock). Udev fires the event based on the usb parameters, and then my script validates that it is actually *my* phone that is connected and not a similar model, and then unlocks the screen.

Similarilly the reverse happens when the phone is undocked, the screen locks.

This is nice and straight forward to implement, can be done in any language of choice and work{s,ed} with Gnome, KDE, or anything else which implements the freedesktop api properly 

> What about having a PAM module?
Needing to write a custom PAM module is not as straight forward and simple or as flexible, and would instead of just checking the one device that was plugged in, would require enumerating all the devices and checking if they are valid. (Using something like https://github.com/jeroennijhof/pam_script would get rid of the first problem, but still not the second)

> The correct way to implement custom unlock functionality is by providing a custom greeter theme
Writing a custom greeter is an even less desireable approach as it becomes very specific to KDE >4.10.

> mapping a list of devices which are allowed to trigger the authentication.
Having support for this in the locker is great, but still removes the ability to have a nice generic solution that works regardless of which desktop environment is currently in use.


- Shane

Created attachment 85920 [details]
Unlock via dbus with SetActive(false)

I'll just leave the patch here for those who might need it.

BTW, this logind thing seems somewhat reasonable. Here is how I see it:
One's custom daemon watches for specific event (phone attached, USB drive plugged-in, etc.), checks the contents of the drive, and determines its owner, checks owner's config and, if it decides that this kind of authentication is valid, enumerates all the sessions of this user and tells logind to Unlock them. This is proper multi-seat (multi-session, etc.)
One issue here is that the `Session.Unlock` method is annotated with `@org.freedesktop.systemd1.Privileged("true")`, i.e. only root processes are allowed to call it.

This may not be useful since this is marked as for 4.10.  I am on 4.12.3.  Running the following command has errors alongside logging me out of my system if I run it in a terminal, but running it with BlueProximity ( http://blueproximity.sourceforge.net/ ) I have found success with unlocking when I am close with my bluetooth device, locking when I walk far enough away, and keeping my system from locking out otherwise.  The options I use for it to run are:

Locking command:  qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
Unlocking command:  qdbus | grep kscreenlocker_greet | xargs -I {} qdbus {} /MainApplication quit
Proximity command:  qdbus org.freedesktop.ScreenSaver /ScreenSaver SimulateUserActivity

The only issue that brought me here was that "qdbus" run on a terminal session resulted in a incorrectly set Qt5 version that broke everything.  Once I set it to the right Qt version that matched my KDE install, it worked out again.

On my system, qdbus was symlinked to "/usr/bin/qdbus -> qtchooser" .  I ran "qtchooser" to fix my issues with the wrong Qt version.  This may be of no help to you, but it worked for me in getting some way to write up scripts and rules using qdbus to lock/unlock the system.  I would be interested in adding the "udev" device connect triggers with "@Shane Mc Cormack" 's examples.

FYI (offtopic)
You are always free to ude `dbus-send` instead of `qdbus` or whatever. Like this:

$ dbus-send --session --type=method_call --dest=org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver.Lock
$ dbus-send --session --type=method_call --dest=org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver.SetActive boolean:false

> This functionality has existed since KDE3 days, (`dcop kdesktop
> KScreensaverIface quit`) then more recently as `qdbus
> org.freedesktop.ScreenSaver /ScreenSaver SetActive False`
> (http://lists.freedesktop.org/archives/xdg/2007-March/009187.html) and then
> in 4.10 the new screensaver/greeter was introduced which removed the nice
> and standard way of doing it (Other screensavers for example
> gnome-screensaver still allow SetActive false on
> org.freedesktop.ScreenSaver last time I checked) but at least still allowed
> unlocked with a bit of fiddling.

Please note that this is not a screensaver, but a screen locker. The 
screensaver mixed up visuals and authentication bits. We cleaned that up and 
made the new locker only about security. Pieces belonging to the saver were 
removed. Our interpretation was that setActive is about the screen saver and 
not the locker. That is the false is for ending the saver but not the locker. 
In the old world the saver was about two things:
* protecting the CRT screen
* locking the screen

These things were not bound together. Thus one could have saving the screen 
(after idle) without locking the screen. In this case the setActive(false) 
makes sense.

The new implementation only cares about locking the screen. Thus the 
setActive(false) does not make sense. In that regard it is irrelevant that 
older versions supported it (as they were screen savers) and also that other 
screen saver implementations support it is irrelevant.

I'm sorry that this broke your workflow.

> 
> My current use for this functionality is a script that is activated by udev
> when my phone is connected to the computer (via a desktop dock). Udev fires
> the event based on the usb parameters, and then my script validates that it
> is actually *my* phone that is connected and not a similar model, and then
> unlocks the screen.
> 
> Similarilly the reverse happens when the phone is undocked, the screen
> locks.
> 
> This is nice and straight forward to implement, can be done in any language
> of choice and work{s,ed} with Gnome, KDE, or anything else which implements
> the freedesktop api properly

And thus logind support will be even better for you.

Git commit 447703ee86fa5f4751e7089cb9ab3976ede952a8 by Martin Gräßlin.
Committed on 02/04/2014 at 08:55.
Pushed by graesslin into branch 'master'.

Add logind integration to screenlocker

A new class LogindIntegration is added to the screenlocker. This class
listens to the Lock and Unlock signals emitted by the session object on
the logind service.

This is integrated with the screenlocker application to start or quit the
lock when the signals are emitted. This means a locked screen is unlocked
when the Unlock signal is received from logind. Logind is a higher
authority for the screenlocker and thus follows the requests from logind.
REVIEW: 117355

M  +5    -1    ksmserver/screenlocker/CMakeLists.txt
A  +15   -0    ksmserver/screenlocker/autotests/CMakeLists.txt
A  +72   -0    ksmserver/screenlocker/autotests/fakelogind.cpp     [License: GPL (v2)]
A  +72   -0    ksmserver/screenlocker/autotests/fakelogind.h     [License: GPL (v2)]
A  +99   -0    ksmserver/screenlocker/autotests/logindtest.cpp     [License: GPL (v2)]
M  +18   -1    ksmserver/screenlocker/ksldapp.cpp
A  +121  -0    ksmserver/screenlocker/logind.cpp     [License: GPL (v2)]
A  +59   -0    ksmserver/screenlocker/logind.h     [License: GPL (v2)]

http://commits.kde.org/plasma-workspace/447703ee86fa5f4751e7089cb9ab3976ede952a8

 Martin Gräßlin, thanks for fixing this issue! But can you describe here (for me and other subscribers and visitors) some example how we can now send via cli unlock signal to screen locker?

> But can you describe here
> (for me and other subscribers and visitors) some example how we can now
> send via cli unlock signal to screen locker?

please see: 
man loginctl

which explains it much better than I could

Murz, let me do this.

First you have to find your current session. There is a number of ways to do this, but probably the easiest one is to query logind by your pid. You do this by calling `org.freedesktop.login1.Manager.GetSessionByPID`:

# qdbus --literal --system org.freedesktop.login1 /org/freedesktop/login1 GetSessionByPID "$$" | cut -d ' ' -f 2 | head -c '-2'
/org/freedesktop/login1/session/c3

logind gives you an object path and now you call `org.freedesktop.login1.Session.Lock` on this object:

> qdbus --system org.freedesktop.login1 /org/freedesktop/login1/session/c3 Lock

And that's it. The only drawback is that you have to do this as root.

Kirill Elagin, thanks for the examples! I will wait this updates in next KDE release and check this.

Martin, can/should this be backported to 4.11? Please set the "Version-Fixed-In" field.

(In reply to comment #26)
> Martin, can/should this be backported to 4.11?

The code uses new Qt 5 features (e.g. lambda slots) and thus I think it's not justified to backport to 4.11.

Hi,

I found this bug report when I was trying to get the unlock part work with blueproximity. I'm on Kubuntu 14.04, KDE 4.13.3. 

The command:
sudo qdbus --literal --system org.freedesktop.login1 /org/freedesktop/login1 GetSessionByPID "$$" | cut -d ' ' -f 2 | head -c '-2'
returns the output: 
/org/freedesktop/login1/session/c8

But when I enter it into the next command:
emre@emre-nb:~$ sudo qdbus --system org.freedesktop.login1 /org/freedesktop/login1/session/c8 Lock

emre@emre-nb:~$ 

Nothing happens, no locking. If I try without sudo, I get Error: org.freedesktop.DBus.Error.AccessDenied

If I try by being root (su), and then put the command, same result as sudo.

What's wrong?

logind integration is only available in 5.x

How do I unlock my screen in KDE 5 without systemd/logind ugliness?

(In reply to Luke-Jr from comment #30)
> How do I unlock my screen in KDE 5 without systemd/logind ugliness?

There is also support for consolekit2, though I don't know how to use that.

Could we just add a dbus Unlock method?

(In reply to Luke-Jr from comment #32)
> Could we just add a dbus Unlock method?

No! That would allow any unprivileged application to unlock the lock screen. The lock screen is there to prevent that. Only a privileged action is allowed to unlock it. This are entering the password or using logind/consolekit as an external (higher privileged) authority.

Don't applications need user privileges to call dbus commands in the first place? If they have dbus access, they can access anything else already, or even ptrace ksmserver to shut it off the hard way. No?

(In reply to Luke-Jr from comment #34)
> Don't applications need user privileges to call dbus commands in the first
> place? If they have dbus access, they can access anything else already,

so what? What does an insecurity in another area say that we should make the lock screen insecure?

> or
> even ptrace ksmserver to shut it off the hard way. No?

Good point: ksmserver needs ptrace protection like it's already the case in kwin_wayland (which holds the lockscreen in the Wayland session). But again: a vulnerability in another area is not an argument to add a vulnerability in another area. We want to fix that mess.

An application executing with user privileges is considered equivalent to the user. That's the way *nix security is designed, and while I agree it could probably use some improvement, the GUI shouldn't be the part trying to change the system's security model, but simply respect it.

Can we please stop that? We won't do the change you want. There is a good enough replacement with logind and consolekit.

Stop what, exactly? Reporting regressions in KDE? Commenting on desirable behaviour? Using KDE at all? (I'm sure if enough users get told off, eventually there will be enough interest in a fork and/or alternative Qt desktop environment...)

Stop the useless discussion. There is a way to unlock the lockscreen through dbus. There won't be another one added.

> There is a way to unlock the lockscreen through dbus.

Ok, I missed this point entirely. Sorry for the useless discussion. What is the current way to do this?

(In reply to Luke-Jr from comment #40)
> > There is a way to unlock the lockscreen through dbus.
> 
> Ok, I missed this point entirely. Sorry for the useless discussion. What is
> the current way to do this?

E.g. with logind it's
qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.UnlockSession <sessionId>

The sessionId can also be queried through DBus, I kindly ask to check logind documentation for it. I don't know how to do it with consolekit, though.

Sigh, systemd and Consolekit are not dbus.

(In reply to Luke-Jr from comment #42)
> Sigh, systemd and Consolekit are not dbus.

see and that's the stupid discussion which you should stop to do. I just gave you a dbus command which will unlock the session. That's what you asked for. It's dbus. Who implements the interface is completely irrelevant. You can even write a small tool which does nothing else than to emit the dbus signal the lockscreen listens to if you want. Can all be done without using systemd or consolekit. It's all pure dbus - check the code, it only interacts with dbus.

Service 'org.freedesktop.login1' does not exist.

(In reply to Luke-Jr from comment #44)
> Service 'org.freedesktop.login1' does not exist.

As I said just above: you can write your own small tool which implements it. That's what we did in the unit tests: https://quickgit.kde.org/?p=kscreenlocker.git&a=blob&h=7266d4a0ba1b7a0ff6ddba62fec55ef752a8cd37&hb=d20449d80bf5e0efc2abd232af01ed59f3723acb&f=autotests%2Ffakelogind.cpp - feel free to use that class, create your own tool out of it and start it.

Okay, Gentoo is finally forcing me to install a logind. But this still doesn't work.

# sudo qdbus --literal --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.GetSessionByPID "$$"
Error: org.freedesktop.login1.NoSessionForPID
PID 59957 does not belong to any known session
# loginctl 
No sessions.

GetSessionByPID is known to be broken. 
That's not a KDE issue, we don't write logind. See systemd

Or just use loginctl directly.

or use /org/freedeskto/login1/session/auto

Simple enough now using loginctl as a privileged user for example:

    sudo loginctl lock-sessions; sleep 3
    sudo loginctl unlock-sessions

Therefore without specifically needing to call with sudo, you can easily write up a systemd service to lock or unlock as needed. Further logic can be added for specific sessions, conditions, etc.

Sorry, missed mentioning examples for your own session:

    loginctl lock-session; sleep 3
    loginctl unlock-session

Use as needed.

$ loginctl lock-session
Failed to issue method call: Is a directory
$ loginctl unlock-session
Failed to issue method call: Is a directory

(In reply to Luke-Jr from comment #50)
> $ loginctl lock-session
> Failed to issue method call: Is a directory
> $ loginctl unlock-session
> Failed to issue method call: Is a directory

I tried to look up any obvious differences in my setup. This works on Ubuntu 20.04.1.  Depending on your setup, this seems to be a systemd setup issue.  Others show the following although not related: https://www.reddit.com/r/archlinux/comments/bl9vcf/loginctl_no_such_file_or_directory/

I don't (and hope to never) use systemd... elogind is what I finally let Gentoo install.

I also don't like/use any fancy session management. Just CLI login and startx.