From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from extdelivery1.dodo.com.au (extdelivery1.dodo.com.au [123.2.6.232]) by mail.server123.net (Postfix) with ESMTP for ; Sun, 27 Mar 2016 19:57:02 +0200 (CEST) Received: from extspam0.internal (extspam0.internal [10.20.4.13]) by extdelivery1.dodo.com.au (Postfix) with ESMTP id 52FEF2121C for ; Mon, 28 Mar 2016 04:57:00 +1100 (AEDT) Received: from extrelay0.dodo.com.au (extrelay0.internal [10.20.4.23]) by extspam0.internal (Postfix) with ESMTP id C5B70208AA for ; Mon, 28 Mar 2016 04:56:40 +1100 (AEDT) Received: from hjbmx.ddns.net (101.106.150.122.sta.dodo.net.au [122.150.106.101]) by extrelay0.dodo.com.au (Postfix) with ESMTP id AF2EC202E9 for ; Mon, 28 Mar 2016 04:56:40 +1100 (AEDT) Received: from [192.168.0.100] (hjb.ddns.net [192.168.0.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by hjbmx.ddns.net (Postfix) with ESMTPSA id 614E21C0AAA for ; Mon, 28 Mar 2016 03:56:40 +1000 (AEST) References: <56F6A1A2.4050805@dodo.com.au> <20160327165226.GB16068@yeono.kjorling.se> From: Hugh Bragg Message-ID: <56F81EBA.9020700@dodo.com.au> Date: Mon, 28 Mar 2016 03:56:10 +1000 MIME-Version: 1.0 In-Reply-To: <20160327165226.GB16068@yeono.kjorling.se> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [dm-crypt] concurrency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 28/03/2016 2:52 AM, Michael Kjörling wrote: > On 27 Mar 2016 00:50 +1000, from hughbragg@dodo.com.au (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.) >