Re: [dm-crypt] concurrency

[Hugh Bragg <hughbragg@dodo.com.au>]

Thanks again for the feedback.
I take you points. Actually neither virtualbox shareable disk nor shared
folder are on any network so that wouldn't be a problem in those cases.
In the other case of an actual network share, I see no reason why the
data couldn't be shared if it was implemented to do so. ie.
Decrypt/Encrypt as the point of use and always flush data immediately.
It's a pity it isn't as in the new world of cloud storage, this would be
very useful. I'd thought this would be obvious these days.
I've seen a few solutions, but they're all proprietary and non-standard
or poorly maintained.
I'm investigating CryFs now, but it's non standard. encfs is good if the
maintainers were more active.

Hugh
On 27/03/2016 2:33 PM, Arno Wagner wrote:
> Hi Hugh,
>
> quite frankly, what you are doing is likely to corrupt your 
> filesystem beyond recovery pretty fast. It will also corrupt 
> data. Filesystems are _not_ designed to have changes on the 
> underlying block-layer without being notified. The only case 
> where this is safe is a read-only filesystem. You are tampering 
> with the fundamental assumptions the filesystem-designers 
> have to make.
>
> If you want a filesystem that is not read-only to be visible 
> in several places, you need to distribute it at or above the 
> filesystem layer. Nothing else works. 
>
> That said, depending on your use-case, there may be options.
> One is a read-only export and a different mechanism for 
> updates. You could tunnel NFS over OpenVPN or SSH or the like.
> You may also be able to use rsync/rdiff-backup or even SVN
> or git to synchronize data.
>
> But putting the raw, LUKS-encrypted block device out there,
> mapping it in different machines and and then mounting 
> read-write it is not a viable solution and cannot be one. 
> Sorry. This is a case where security takes some effort that 
> cannot be avoided.
>
> Regards,
> Arno
>
>
>
>
> On Sun, Mar 27, 2016 at 01:53:21 CET, Hugh Bragg wrote:
>> Hi Arno,
>>
>> Thanks very much for taking time to respond Arno.
>> You're right. I'm sharing a virtual disk and trying to decrypt and mount
>> that in multiple locations.
>> The other thing I tried was mounting a disk image on a virtualbox shared
>> folder.
>>
>> I don't want to need a dedicated server to deliver a decrypted
>> filesystem because I don't want the decrypted data to be exposed to the
>> network. I understand I could use secure communications, but this is all
>> way too much overhead compared to what I'm trying to achieve.
>>
>> >From your response I gather that the answer is no, It doesn't support
>> sharing of the raw block device with concurrent mounting.
>> Is this just due to implementation or are there functional reason why
>> this is so?
>>
>> I've been trying encfs and ecryptfs too, but they suffer from security
>> and functional deficiencies.
>> Is there some other solution that does support this setup?
>>
>> Thanks,
>> Hugh
>>
>> On 27/03/2016 6:06 AM, Arno Wagner wrote:
>>> Hi,
>>>
>>> in order to have a shared filesystem work, you need, well,
>>> a shared filesystem! Do not under any circumstances share
>>> the block-device or the LUKS-remapped decrypted block
>>> device. I suspect you do soemthing like that, because
>>> otherwise the question would not even arise. 
>>>
>>> The rigth way to do this is 
>>>   raw-block-device -> LUKS decrypted block device -> Filesystem
>>>   -> export of that filesystem, e.g. via NFS.
>>>
>>> (last two steps possibly one with other network filesystyems)
>>>
>>> Of course, NFS (or the network filesystem of your choice)
>>> has some transactional assurances and is missing others.
>>> For example, on NFS, nothing is atomic, except locks 
>>> or rename operation (as far as I remember).
>>>
>>> But if you do follow the right layering, what you have is
>>> not a LUKS problem at all, but something stemming from the
>>> filesystem layer and possibly wrong assumptions about the 
>>> assurances it offers.
>>>
>>> Regards,
>>> Arno
>>>
>>>
>>>
>>> On Sat, Mar 26, 2016 at 15:50:10 CET, Hugh Bragg wrote:
>>>> 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.
>>>> Specifically, virtualbox shareable disks and shared folders, but
>>>> potentially, any nfs/cloud storage.
>>>>
>>>> Am I missing something or is there another tool for this case?
>>>> _______________________________________________
>>>> dm-crypt mailing list
>>>> dm-crypt@saout.de
>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt