----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125641/#review87316 -----------------------------------------------------------
"I originally didn't want to pass it over dbus, but in the end it doesn't matter because as soon as the session is unlocked (at this point the hash is sent), the wallet would be unlocked and a possible attacker would have access to its data anyway. But I'm open to suggestions on improvements." I don't understand. If the wallet is unlocked, why are you trying to unlock it? +1 on the use-cases; I don't know much about kwallet's or PAM's internals to thoroughly review the code. This is important - needs a review. - Boudhayan Gupta On Oct. 16, 2015, 10:22 p.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125641/ > ----------------------------------------------------------- > > (Updated Oct. 16, 2015, 10:22 p.m.) > > > Review request for KDE Frameworks and Valentin Rusu. > > > Repository: kwallet > > > Description > ------- > > A use-case: kwallet gets locked with lockscreen, eg. on Plasma Mobile, > unlocking the screen would also unlock kwallet through PAM. > > Another use-case: automatic login that shows lockscreen after booting, > unlocking that session would also unlock kwallet through PAM. > > This requires a small change in kwallet-pam. > > Now to the patch itself. When a user authenticates via lockscreen, PAM can > start the kwalletd process and pass the auth hash token to it. In case the > kwalletd process is already running, this patch would check if the wallet is > opened and if not, it would pass the PAM hash token over dbus to the running > kwallet instance which would unlock the running wallet. If it is unlocked, > nothing would happen. > > I originally didn't want to pass it over dbus, but in the end it doesn't > matter because as soon as the session is unlocked (at this point the hash is > sent), the wallet would be unlocked and a possible attacker would have access > to its data anyway. But I'm open to suggestions on improvements. > > > Diffs > ----- > > src/runtime/kwalletd/main.cpp fbab58d > > Diff: https://git.reviewboard.kde.org/r/125641/diff/ > > > Testing > ------- > > I've created a special PAM profile which has > > auth optional pam_kwallet5.so lockscreen > kwalletd=/opt/kde5/bin/kwalletd5 > > ran kcheckpass -c myprofile and kwallet5 got started and unlocked. Then I > locked the wallet using kwalletmanager5, ran kcheckpass -c myprofile again > and the running kwallet5 instance got unlocked. > > > Thanks, > > Martin Klapetek > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
