On 28/03/2016 2:52 AM, Michael Kjörling wrote: > On 27 Mar 2016 00:50 +1000, from hughbragg@xxxxxxxxxxx (Hugh Bragg): >> Should I be able to use Luks concurrently on a shared filesystem from >> different computers? >> Attempts so far have failed with writes not being seen from the other >> computer until both computers remount the filesystem or reboot. > As a thought experiment, try removing LUKS from the equation. For the > purposes of what you seem to be asking, LUKS is just a part of the > physical storage layer. > > Instead of [unencrypted physical storage device + LUKS container] > providing the feature "encrypted storage of user-selected data", > consider the case [self-encrypting physical storage device] which > provides the same feature "encrypted storage of user-selected data" > but this time without involving LUKS or dm-crypt. > > _Would you expect what you have in mind to work after making that > single change?_ Yes, in the case of virtualbox storage, if the disk was self encrypting it would work. Sounds interesting. Are there any opensource tools that can do this? I was expecting lvm on luks on a virtual disk to do this, but it failed. For network shares, this wouldn't be any good. I wouldn't want to store the key on the cloud server. > If not, then there is no reason to expect it to suddenly start working > when you introduce an additional component (LUKS) into the _physical_ > storage stack. And as far as the file system is concerned, LUKS very > much _is_ a part of the physical storage stack. (There would be > nothing _architecturally_ weird with a HBA that itself runs LUKS and > exposes the decrypted container while writing the encrypted data to > the actual physical storage device. It would come with some fairly > serious design challenges if one wants to make it secure, however.) > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
