D28745: Skip caching thumbnails on encrypted filesystems

[Marcin Gurtowski]

marcingu added a comment.


  In D28745#676566 <https://phabricator.kde.org/D28745#676566>, @sitter wrote:
  
  > In D28745#676452 <https://phabricator.kde.org/D28745#676452>, @marcingu wrote:
  >
  > > !PING.
  > >  I need help from someone with good understanding of Solid to continue.
  > >
  > > I'm don't know how to determinate if StorageAccess device is encrypted or not. I wanted to use  `StorageVolume::usage`, but it's not available for all types of devices and doesn't equal `encrypted` for LUKS encrypted volumes.
  >
  >
  > At a glance the problem here is actually that depending on the setup the mounted volume isn't necessarily the encrypted volume. e.g. if you make a LUKS encrypted btrfs on /dev/sda1 then sda1 is type LUKS encrypted, but to actually use it that device gets decrypted and mapped into a different name /dev/mapper/luks-123 which is type btrfs and not encrypted. It is only the mapped one that gets mounted which is why the encryption context gets lost along the way.
  >
  > I'm afraid this will need some adjustment in solid because currently we don't carry that information anywhere that I can see. It is however in the data of udiks2 behind the scenes (dbus property org.freedesktop.UDisks2.Block.CryptoBackingDevice which is a dbuspath of the encrypted backing object) so it should be readily available, just needs putting somewhere in solid. This is also represented in the sysfs through a slave relationship between the two block devices, but I'm guessing using that over udiks2 isn't nearly as portable.
  >  Where to put it I don't really know, probably a new method on one of the interface classes CryptoBackingUDI which returns the UDI representing the backing device.
  
  
  Could this be delegated onto someone who knows Solid or should I try figuring it out by myself?
  
  > On an entirely unrelated note I for one would simplify the sharesFilesystemWithThumbRoot to check if the thumb root is encrypted and always cache the thumb if that is the case. Whether or not the devices are the same seems unnecessarily nitpicky so long as the results are encrypted if the originals were. Otherwise you run into awkward cases where a users has a system drive and a data drive, both encrypted, but because they are different we effectively disable all thumbnail caching for the data drive.
  
  I was thinking about that, but decided against it on the slim chance that person having access to encrypted home might not necessarily have same access to a vault or other volume that got mounted on the system, by for example different user of the same machine.

REPOSITORY
  R320 KIO Extras

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

To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns, dfaure
Cc: sitter, dfaure, thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20201008/19903c13/attachment.htm>