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 -- Кирилл Елагин
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
