Re: [dm-crypt] concurrency

[Arno Wagner <arno@wagner.name>]

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

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier