Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated April 3, 2014, 5:15 p.m.) Review request for kde-workspace and Aaron J. Seigo. Changes --- Added a signal handler for SIGUSR1 that switches the greeter to immediateLock mode. The locker now sends that signal instead of killing the greeter. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description (updated) --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Diffs (updated) - ksmserver/screenlocker/greeter/greeterapp.h 8b79188 ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 ksmserver/screenlocker/greeter/main.cpp d898734 ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing (updated) --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Thanks, Wolfgang Bauer
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
On March 26, 2014, 11:07 p.m., Thomas Lübking wrote:
you could sighup or sigusr the greeter process and have it
setImmediateLock(true);
desktopResized();
in return
Wolfgang Bauer wrote:
I agree, this would be a bit nicer...
But I tried it and cannot get it to work.
My signal handler is called, and both setImmediateLock(true) and
desktopResized() are called, (I verified this with debug output statements)
but the password dialog still doesn't show.
Wolfgang Bauer wrote:
Oops, sorry. I just noticed that the signal handler is apparently only
called when I run kscreenlocker_greet manually (and do kill -USR1), but not
when the locker runs it.
Will have to investigate this.
Wolfgang Bauer wrote:
Forget my previous comment.
The signal handler was actually called all the time.
But setImmediateLock(true); followed by desktopResized(); DOES NOT
have any (visual) effect.
I have yet to find out what else to call to make that dialog appear. Any
idea maybe?
Calling exit(1) does work, but that's not much different to killing the
greeter I suppose... ;-)
Thomas Lübking wrote:
Ahhh... me was too smart in the multiscreen code ;-)
the for loop in desktopResized() (which is relevant for the
m_immediateLock handling) won't be entered since no screen changed.
Instead you'd run
for (int i = 0; i desktop()-screenCount(); ++i) {
QDeclarativeProperty(m_views.at(i)-rootObject(),
locked).write(true);
}
aside fixing the m_immediateLock value.
Sorry for the false information.
Ok, that works.
Thank you for the help! :-)
Btw, I noticed that UnlockApp::setLockedPropertyOnViews() basically does the
same, so I'm just calling that instead to avoid code duplication.
I have uploaded a new patch.
- Wolfgang
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117091/#review54247
---
On April 3, 2014, 5:15 p.m., Wolfgang Bauer wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117091/
---
(Updated April 3, 2014, 5:15 p.m.)
Review request for kde-workspace and Aaron J. Seigo.
Bugs: 327947 and 329076
http://bugs.kde.org/show_bug.cgi?id=327947
http://bugs.kde.org/show_bug.cgi?id=329076
Repository: kde-workspace
Description
---
If the screen locker is set to not require a password to unlock, it will not
show the password input field even when the powermanagement settings suspend
the system and are set to require a password after resume (when it was
already running at that point).
This locks people out of their system.
This patch adds a signal handler for SIGUSR1 that switches the running
greeter to immediateLock mode. The locker sends that signal to make sure the
greeter shows the password input field when necessary.
Diffs
-
ksmserver/screenlocker/greeter/greeterapp.h 8b79188
ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85
ksmserver/screenlocker/greeter/main.cpp d898734
ksmserver/screenlocker/ksldapp.cpp 3dfcc9e
Diff: https://git.reviewboard.kde.org/r/117091/diff/
Testing
---
Disable Require password after in the screen locker settings (the default),
set it to start after 1 min. (for easier testing).
Enable Suspend session after and set it to 2 minutes. (set the action to
Suspend, Hibernate, or Lock Screen, doesn't matter)
Make sure Lock screen on resume is enabled in the powermanagements
Advanced Options (it is by default).
After 1 minute the screen locker kicks in, and doesn't require a password.
After 2 minutes the session gets suspended, hibernated or locked, and
requires a password to resume.
Without this patch no password dialog is shown, the user cannot resume the
session by entering the password.
With this patch this works: there is a password input field, the session is
unlocked when the user enters the password.
Thanks,
Wolfgang Bauer
Re: Review Request 117345: Fix crash in KIO due to exposing inconsistent views of internal data.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117345/#review54950 --- The patch looks ok and it looks like you know what you're doing, so +1 from me. Your patch is applied on kdelibs/kio. kdelibs has been split into different frameworks, so you want to do it on the kio repository. - Aleix Pol Gonzalez On April 3, 2014, 2:29 a.m., Simeon Bird wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117345/ --- (Updated April 3, 2014, 2:29 a.m.) Review request for kdelibs. Repository: kdelibs Description --- Fix crash in KIO due to exposing inconsistent views of internal data. This can be triggered by renaming a directory while one of the files in it is open in gwenview. It occurs because when KDirListerCache::emitRedirections is called, itemsInUse contains the old url. However, KDirLister::Private::redirect changes lstDirs to the new url. Thus at this point lstDirs contains an item not in itemsInUse, which causes an assertion if forgetDirs is called. In gwenview, the redirection signal is connected to openURL. This calls forgetDirs, and causes the assertion. The solution: update itemsInUse *before* emitting redirections. This fixes the crash, but gwenview opens the first file in the new directory instead of the file open before renaming. This is probably an unrelated gwenview bug. I wrote this for kdelibs 4, but the code seems unchanged in kdelibs 5. Diffs - kio/kio/kdirlister.cpp aad6893f47eba81c3f78ed1ca7327adf6fb587bb Diff: https://git.reviewboard.kde.org/r/117345/diff/ Testing --- It fixes the crash! It might break something else. Thanks, Simeon Bird
Re: Review Request 117157: Unlock session via DBus
On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote: In fact the list of folders and keys present in KWallet (though not their values) can be queried without unlocking KWallet, or even causing it to prompt to unlock. AFAIK, all data access operations on KWallet require it to be opened first (KWallet::openWallet). That will surely trigger password prompt for legacy encrypted wallets. The GPG back-end wallets only trigger pin entry the first time, subsequent requests would simply open the wallet, as GPG private key is already unlocked. Could you please elaborate more on the possibility to enumerate the keys without opening the wallet? -- Valentin Rusu irc: valir signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
On Fri, April 4, 2014 02:20:28 Valentin Rusu wrote: On Sunday, March 30, 2014 05:25:58 PM Michael Pyne wrote: In fact the list of folders and keys present in KWallet (though not their values) can be queried without unlocking KWallet, or even causing it to prompt to unlock. Could you please elaborate more on the possibility to enumerate the keys without opening the wallet? From the KWallet::Wallet API docs: bool Wallet::keyDoesNotExist(...): Determine if an entry in a folder does not exist in a wallet. This does not require decryption of the wallet. This is a handy optimization to avoid prompting the user if your data is certainly not in the wallet. Wallet::folderDoesNotExist() has similar verbiage. enumerating is overstating the case here since there's no direct support for enumerating folders or keys. But all the same, it's not hard at all to brute- force potential folder or key names using the same method used to guess valid Coinbase user identities that just hit the news. Of course if an attacker is running code they'd probably just find it easier to open the .kwl directly and read the folder and key names, since apparently those are stored unencrypted, if the API docs are to be believed. Note that there is a valid use case for this feature: It would be tremendously annoying for a user to have to open their wallet just so an application can verify if it does or does not have an entry stored in the wallet. Instead the application can defer opening the wallet (and forcing the password prompt0 until the value is actually needed. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
