Review Request 125641: Allow PAM unlocking of a running wallet

[Valentin Rusu]

> On Oct. 23, 2015, 7:07 p.m., Boudhayan Gupta wrote:
> > src/runtime/kwalletd/main.cpp, line 173
> > <https://git.reviewboard.kde.org/r/125641/diff/1/?file=411052#file411052line173>
> >
> >     Is this necessary? Shouldn't KWallet::Wallet::isOpen() fail nicely if the wallet isn't running?

Well, I agree with that check.


- Valentin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125641/#review87317
-----------------------------------------------------------


On Oct. 16, 2015, 4:52 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, 4:52 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151213/c03439f5/attachment.html>