Review Request 117157: Unlock session via DBus

[Thomas Lübking]

On Sonntag, 30. März 2014 19:26:21 CEST, Thiago Macieira wrote:
> Em dom 30 mar 2014, às 10:10:06, Thomas Lübking escreveu:

>> Unlocking via a dbus command is imo very problematic.

> I disagree. The user already authenticated via their password 
I should have been more precise in the first sentence:

   Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk]


> before they were able to send the D-Bus command in the first place. 
> So why not allow them to unlock?
Because we protect the session, not the shell.

Occasional access will already be stopped by having to use gdb in the first place and even then it's possible to protect the process from manipulation by the same UID.

>> If we require a password, the user would be trapped into having it in his
>> shell history or invited to store it (plaintext) on disk. If such tool
>> would be required, it could work by having the user solve a "captcha"
>> before reading the PW from stdin (to prevent automization)
>> 
>> $ kscreenlocker unlock ...
>
> Please don't invent authentication mechanisms.

I didn't even remotely try - this was still about the password enriched dbus unlock (and how to prevent the PW from ending up on the disk)

Cheers,
Thomas