arno at wagner.name
Sun Mar 27 06:33:55 CEST 2016
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.
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
> 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?
> 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 at saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> dm-crypt mailing list
> dm-crypt at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt