Re: [dm-crypt] u?mount (8) helper script for luks encrypted disks

[Matthias Schniedermeyer <ms@citd.de>]

On 29.08.2013 19:56, .. ink .. wrote:
> On 29.08.2013 07:50, Milan Broz wrote:
> > > On 26.8.2013 10:23, Matthias Schniedermeyer wrote:
> > > >Personally i "solved" this by renaming /bin/mount to /bin/mount.orig
> > > >and putting a shell-script as /bin/mount that checks if i want to mount
> > > >a /dev/mapper/XXX and does the setup of XXX before it calls
> > > >/bin/mount.orig.
> > >
> > > Underlying device construction can be very complex task sometimes
> > > (it can be combination of lvm, mdraid, multipath, partitions and
> > whatever.)
> > >
> > > So while it works for your use case, it will not work for other.
> >
> > And there will never be a "one size fits all" solution for this.
> >
> > Sure, someone could create a "monster" that could cope with anything.
> > But that wouldn't be KISS.
> >
> >
> Its possible to have a "one size that fits all" without it being a "monster"
> 
> In your "mount" script,take a path to an arbitrary device and then do the
> following.
> 
> On mounting:
> 
> 1. call "blkid" and check the file system on the device,if its present and
> its not "crypto_LUKS",then its a device with a normal file system,just
> mount it normally.

And i would crash & burn right here. Not all encryption is LUKS!

I use loopAES v3 encryption (a.k.a. lmk3).

There are zero identifiable features in a file or block-device that is 
loopAES (any version) encrypted. Just like plain encryption. And if i 
understood it correctly, this is also true for e.g. a Truecrypt 
container.

A "monster" would natuarally support any and all encryption models, that 
includes encryption models that can't be identified.

And my personal model has also a splash of special-sauce. My "whole 
disc" encryption is from sector 8 until the end of device. So i can put 
a dummy-MBR on each HDD in which i can stamp the name. This name in turn 
is used in a udev-rule to create a symlink that identifies the connected 
HDD. And last but not least, there is the matching autofs configuration, 
so i can just cd /misc/<name> after connecting the corresponding HDD.

> 2. if the file system is found to be "crypto_LUKS",then call cryptseup to
> unlock the path with whatever tool policy you have to create the mapper
> path.Then call "blkid" against the mapper path to check the file system and
> then mount the mapper normally.
> 
> Its just that simple.

Only if you restrict it to simple cases, but that would be KISS and not 
"monster".

> On unmounting.
> 1. Look at the path to be unmounted,if it starts with "/dev/mapper/" then
> it could an mdraid path or a cryptsetup mapper path or something else.Its
> easy to check which one is it.
> 2. If its encrypted mapper path,then unmount the mapper and then call
> cryptsetup to unmap the mapper.If its not encrypted then just unmount.
> 
> The whole thing seem easy enough and can be done by adding a handful of if
> statements in the script

Umount-case (in the future(?)) should be a solved problem by the 
autoclose-feature, so the mapper is automatically destructed after the 
filesystem is umounted. The interesting question, altough not for me, is 
if that works with stacked mappings.




-- 

Matthias