D23384: [WIP] Adding support for mounting KIOFuse URLs for applications that don't use KIO

Harald Sitter noreply at phabricator.kde.org
Tue Dec 3 12:21:56 GMT 2019


sitter added a comment.


  I haven't read everything in great detail... but...
  
  Quick braindump of musing I did elsewhere: as far as credential hand-over is concerned this is likely a problem that needs a workaround for now as there is no clear cut solution that I am aware of. It may be worth talking to gnome about this and come up with an xdg standard for this.
  
  The trouble is: we can't pass credentials in the URL as that'd be an exec argument and that would by default leak into /proc where the credential is then world readable. What we need is an additional system to pass credentials.
  
  IMHO what likely is the smartest choice to is to have credentials stored in a running Secret Service API daemon and have clients then get the credentials out of there. Possibly with some additional ephemeral storage type (e.g. we cache credentials in kiod but store them in kwallet currently, that gives two points where we can leak secrets. if we were to move everything into the secret service we'd have a single service that needs securing). Just my opinion on the matter.
  
  Until we have a cross desktop spec defining the passing of credentials I imagine we can't really let applications handle URLs for which we have/need credentials and I suspect determining if we need credentials is also a bit tricky.
  The opposite extreme is to always pass when X-KDE-Protocols is set and assume that the applications are actually working correctly (e.g. vlc ought to talk to kiod/KPasswdServerClient to get credentials, otherwise its declaration of X-KDE-Protocols is incorrect and you are looking at a bug in vlc. at the very least it should throw up its own auth dialog if it doesn't know what to do).

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D23384

To: feverfew, fvogt, davidedmundson, dfaure, ngraham
Cc: broulik, sitter, davidedmundson, kde-frameworks-devel, ngraham, LeGast00n, GB_2, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191203/d8e25640/attachment.html>


More information about the Kde-frameworks-devel mailing list