[systemd-devel] Proper use of the Session.Unlock method call

[Kirill Elagin]

Hi,

There are plenty people who have some kind of automatic session unlocking
set up.
Examples are: BT phone proximity, USB-drive being plugged in, etc.
This is normally done via DBus `ScreenSaver.SetActive(false)` call, but
this interface is not
well-documented and, actually, it seems that this call is intended only for
screen saver disabling
and is not meant for session unlocking.

This is exactly the way the guys from KDE decided to interpret the
interface:
they take any possibility to unlock a session without entering the user's
password to be a bug.[1]
When presented with a number of convincing arguments in favour of some kind
of auto-unlock
functionality, their answer now is “KDE session manager is going to respect
logind's Lock/Unlock
signals, so do your unlocking stuff through logind”.

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?

Here is how I see it:
* User attaches his USB-drive.
* Special udev invokes a helper.
* The helper looks inside the drive and determines the owner.
* Checks the owner configuration, performs the drive authentication.
* If everything is fine, it enumerates all the sessions of this user
(proper multi-session!)
* and unlocks them.

The issue here is that the `Session.Unlock` method is privileged, so I'm
not sure yet
how to go with that. In case of udev everything is OK as it's running as
root, but
this is not always the case. So, `pkexec`? Or maybe something completely
different?


  [1]: https://bugs.kde.org/show_bug.cgi?id=314989

--
Кирилл Елагин
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140403/8e2cb2ae/attachment.html>