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

Reply via email to