Review Request 117157: Unlock session via DBus

[Thomas Lübking]

On Sonntag, 30. März 2014 20:53:01 CEST, Thiago Macieira wrote:

> Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu:
>> Unlocking via a dbus command [that requires password authentication] is
>> imo very problematic [because that will end up exposing the password
>> on-disk]
>
> How does the password end up on disk?

One of the use-cases in the linked bug is to invoke this by pam_usb or some bluetooth script. If the dbus call would require a password, the script could end up looking like
   qdbus org.kde.kscreenlocker unlock 1ns3cur3




> In the past, I could kill a process when I had improperly installed KDE and
> the greeter couldn't authenticate via PAM.
> Now I have to kill ksmserver or cause the session to exit via D-Bus.

Actually the major reason (afaiu) behind moving the lock to ksmserver is to make crashing the locker process worthless.
Iirc it happened after AllowClosedownGrabs was (accidentally) unconditionally turned on in Xorg (but that only qualifies as trigger and you'll have to ask Martin on direct motivations ;-)

The development situation is special and actually what i had in mind when saying

   any way to circumvent authentication to this very session should be guarded by a special "knowwhatido" key [or require active authentication]

I do certainly not think that the absolutely only way to open the lock should be the greeter GUI, but i do think that one should authenticate to the locker, what an open shell does not provide.
Since you however implied that broken KDE ./. PAM might be a reason for a side entrance, that side entrace key must not rely on PAM.

--> We could check the last login time of the user and compare that to either
a) start time of the lock
b) 3 minutes

and accept an explicit dbus quit request if by this it's clear that the user has just authenticated to the system, implicating authentication to the locker.

> All processes by the same user should be trusted.
Ever forgot an open VT1?

Cheers,
Thomas