On Sonntag, 30. März 2014 23:25:58 CEST, Michael Pyne wrote:
I'll note I've actually done this before, during the development process for the new QML-based screenlocker.
Me fixed the issue in the greeter code (while doing multiscreen/input handling), installed the greeter and SIGTERM'd the present one =) Neither is fun, of course.
With that in mind I'd love to have a "more official" way to tear down the screenlocker from a separate same-user login.
I don't think there's fundamental disagreement on this (esp. not in the developing context) - just on what challenge is required to this side entrance. Eg. i'd personally not object unlocking if there's a login (of yours) which is more recent than the lock and/or "recent enough".
wait until you figure [...] KWallet
That issue is known (to me at least). In a non trustworthy environment i simply close kwallet before leaving the system unwatched because of this. (If I was more paranoid, i'd keep it on a usb key) However, I'm sure you don't want to justify security issues by other security issues :P
If they can gain access to a TTY login we are already screwed
leaving aside the present issue (/MainApplication quit being exposed to dbus) and given ptrace (gdb solution) is denied: in how far? (beyond killing the session, ie. being a nasty little jerk ;-) Cheers, Thomas
