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
