D28745: Skip caching thumbnails on encrypted filesystems

Harald Sitter noreply at phabricator.kde.org
Thu Oct 8 11:57:13 BST 2020


sitter added a comment.


  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.
  
  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.

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/kfm-devel/attachments/20201008/f2ea3463/attachment.htm>


More information about the kfm-devel mailing list