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
