<div dir="ltr">Hi,<br><br>There are plenty people who have some kind of automatic session unlocking set up.<br>Examples are: BT phone proximity, USB-drive being plugged in, etc.<br>This is normally done via DBus `ScreenSaver.SetActive(false)` call, but this interface is not<br>

well-documented and, actually, it seems that this call is intended only for screen saver disabling<br>and is not meant for session unlocking.<br><br>This is exactly the way the guys from KDE decided to interpret the interface:<br>

they take any possibility to unlock a session without entering the user's password to be a bug.[1]<br>When presented with a number of convincing arguments in favour of some kind of auto-unlock<br>functionality, their answer now is “KDE session manager is going to respect logind's Lock/Unlock<br>

signals, so do your unlocking stuff through logind”.<br><br>So, my question is this: what is the intended use of the `Session.Unlock` call, is it acceptable to employ this method to achieve this kind of auto-unlocking functionality?<br>

<br>Here is how I see it:<br>* User attaches his USB-drive.<br>* Special udev invokes a helper.<br>* The helper looks inside the drive and determines the owner.<br>* Checks the owner configuration, performs the drive authentication.<br>

* If everything is fine, it enumerates all the sessions of this user (proper multi-session!)<br>* and unlocks them.<br><br>The issue here is that the `Session.Unlock` method is privileged, so I'm not sure yet<br>how to go with that. In case of udev everything is OK as it's running as root, but<br>

this is not always the case. So, `pkexec`? Or maybe something completely different?<br><br><br>  [1]: <a href="https://bugs.kde.org/show_bug.cgi?id=314989">https://bugs.kde.org/show_bug.cgi?id=314989</a><br clear="all"><div>

<div dir="ltr"><div><br></div>--<br>Кирилл Елагин</div></div>
</div>