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

[Lennart Poettering]

On Thu, 03.04.14 21:42, Kirill Elagin (kirelagin at gmail.com) wrote:

> 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?

Hmm, I mostly took this call over from ConsoleKit. Given that the method
is called "Unlock" it should probably really unlock, and not ask the
user for any password. It's a priviliged method call, hence this should
be safe.

> 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?

Yeah, this sounds like a valid usecase for Unlock() to me, and yes,
you'd have to add pkexec or sudo or some other kind of authenticated
security transition to this if you want to open this up for specific
unpriviliged programs.

Lennart

-- 
Lennart Poettering, Red Hat