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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
