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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
