RFC: Moving KWallet Password dialog into Plasma

[Volker Krause]

On Friday 20 July 2012 17:58:04 Martin Gräßlin wrote:
> Hi all,
> 
> the problems around review request #105628 and getting KWallet's Password
> dialog properly raised above the window it is asking the password for just
> triggered a thought process.
> 
> The main problem here is that $service ask for a password through
> $otherservice. This utterly fails because the $service is not linked
> directly to a window which the window manager would need to properly stack
> the window.
> 
> Now if we think about it in most cases $service is actually a "system"
> service which can be considered belonging to the workspace. E.g. checking
> for mail, logging into your telepathy account and so on.
> 
> Providing a password safe and asking for the master password is also a
> "system" service and should belong into the workspace.
> 
> So here my idea: let's move the password dialog into the desktop shell. Have
> it as a so-called "persistent" notification popping out of the panel and be
> shown on top of all other windows till the user either dismisses it or
> enters the password.
> 
> I think this would solve most of our current issues. There would be one
> place where the dialog is shown to ask for the password, it is visually
> clear that it's a system service which asks for the password and not some
> random malware and if several applications want to open the wallet this
> problem is also nicely solved by e.g. saying "Mail Dispatcher Agent and
> Telepathy need to unlock the wallet".
> 
> So what do you think?

I very much like your idea :)

It fixes exactly the problem we have with Akonadi (KRunner/Plasma Clock 
starting Akonadi, which in turn syncs with some remote service needing a 
password), and for which we haven't been able to find a real solution so far.

I also agree with your security assessment of this, once I can execute code as 
your user, KWallet doesn't really protect much anymore, no matter where the 
password dialog is running. But that's also not what it was designed to 
protect, that's rather someone getting access to your files (different user on 
the same system, stolen hard disk, etc). And that's not compromised by moving 
the password dialog into a different process.

Integration with system passwords would of course be nice, but is IMHO 
completely orthogonal to this.

When looking at KWallet security and usability, there's another aspect that 
came up in discussions during Akademy: The "Do you want to allow application 
foo access your wallet?" dialog. It might give the impression that only 
certain "trusted" applications can access the wallet, which is totally 
misleading. The application name can trivially be faked, and the "allow/deny 
always" decision is simply stored in a plain text config file. 

I assume the intention of this was rather to give users the choice to not 
store data of well-known/well-behaving applications in the wallet (maybe due 
to security concerns). Kinda makes sense, but might be better solvable by a 
corresponding option on the application level (like web browsers do for 
example, and I think most Akonadi agents as well), instead of bothering me 
with yet another dialog when first using KWallet. This also avoids the false 
sense of security.

Regards,
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120721/78a933a3/attachment.sig>