Unable to lock LUKS when LVM VG contained

[schnittchen]

Here's the topology (lsblk output):

NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0   1.8T  0 disk  
├─sda1                                          8:1    0     1T  0 part  
│ └─luks-aa9775a5-a3e7-44bf-ab55-9299c92fb246 254:6    0  1024G  0 crypt 
│   └─disk--home--grp-backups                 254:7    0 465.8G  0 lvm   

Here is how it fails, and the workaround needed:

 ~ ✓ udisksctl unlock -b /dev/sda1
Passphrase: 
Unlocked /dev/sda1 as /dev/dm-6.
 ~ ✓ udisksctl lock -b /dev/sda1
Error locking /dev/sda1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error locking /dev/dm-6 (/dev/sda1): Failed to deactivate device: Device or resource busy
 ~ ✘ sudo vgchange -a n disk-home-grp
  0 logical volume(s) in volume group "disk-home-grp" now active
 ~ ✓ udisksctl lock -b /dev/sda1
Locked /dev/sda1.

Annoyingly, this means I need to use sudo, and graphical tools are out of luck.

[vpodzime]

Not sure what the right thing to do is here. Implicitly deactivating the VG or in general arbitrary storage stack on the unlocked LUKS device is a potentially dangerous operation. Maybe we should add something like a --deactivate option to lock which would do things like this (and also e.g. umount the device)?

[schnittchen]

Please also keep in mind that desktop systems (I assume they communicate via dbus?) will have a need for this, too.

[schnittchen]

Assuming that udisks is asked to lock the disk, what are the dangers of trying to (always) deactivate the volume group connected to a contained physical volume? (Not forcibly, so I am assuming LVM will not let us do so as long as anything is still in use)

[vpodzime]

Assuming that udisks is asked to lock the disk, what are the dangers of trying to (always) deactivate the volume group connected to a contained physical volume? (Not forcibly, so I am assuming LVM will not let us do so as long as anything is still in use)

Well, LVs are block devices, you never 100% know what's running on top of them and how.

[schnittchen]

With that logic, how can udisks ever unlock a crypted volume?

[vpodzime]

With that logic, how can udisks ever unlock a crypted volume?

You mean lock, I guess? Well, trying to do what cryptsetup close would do is one thing, trying to tear down some storage stack on top of the unlocked device is a different thing.

If we limit it to the case where there's LVM on top of the encrypted device, it's quite easy, we can do that and say that we assume vgchange -an on the affected VG is a safe operation that would fail gracefully instead of breaking something (and causing data corruption). The same applies to unmount.

But we will never be able to do this teardown in general. UDisks2 doesn't understand all the possible storage stacks that can be built on top of an encrypted device and it never will.

[schnittchen]

Yes, I meant lock.

Basically, udisks could try the following before doing the actual luksClose step:

• find out if there is a VG which has the disk as a PV (maybe udisks already has that data?)
• if found, issue a vgchange -a n on the VG
• ignore the result (error/ok)
• continue with the lock operation

The error above AFAIK comes from the fact that the kernel knows that the plaintext device is in use, which is because the LVM subsystem marked it as such. The same would happen if instead of being a PV for an active VG, the plaintext device contained a mounted filesystem. I am not sure but I think when dd operates on the plaintext device, the same would happen again.

Maybe some filesystem formatting tools or similar open then close then re-open the device, leaving it in an inconsistent state before re-opening, and udisks locking the underlying device would make the tool abort prematurely. Do we know of any such cases?

[tbzatek]

But we will never be able to do this teardown in general. UDisks2 doesn't understand all the possible storage stacks that can be built on top of an encrypted device and it never will.

Never say never! --> #781

This deactivate functionality is roughly similar to tear-down and can be implemented as an option e.g. of the org.freedesktop.UDisks2.Encrypted.Lock() method.