On Mon, Jun 18, 2007 at 05:36:31PM +0200, Ludwig Nussel wrote: > I'm currently wondering what's the best way to retain the comfort > mount offers for cryptoloop when using dm-crypt instead. With Good topic. > Several people offer scripts that abuse mount's feature to call a > custom helper program for unkown file systems, like > /bin/mount.dmcrypt. That's ugly as one has to specify the real fs in > the options column. Tools like fsck won't recognize that. Hehe.. nice workaround. > There is also this patch > http://people.redhat.com/kzak/util-linux-cryptsetup/util-linux-2.13-pre6-cryptsetup.patch > which utilizes libcryptsetup. Both methods have the disadvantage > that one needs to specify all crypto options in fstab then. I don't work on this experimental patch anymore -- it should be implemented in other way. > IMO the crypto options should stay in /etc/crypttab and /etc/fstab Probably yes. > should only list the mount options. Since there are already means to > process /etc/crypttab mount does not need to do that itself. So what > about adding support for an fstab option that specifes a helper > program to set up the real block device? I'd imagine something like > this in fstab: > > /dev/sdc1 /bar ext2 noauto,user,bhelper=/sbin/crypttabhelper 0 0 I think you have to define final (mapped) device in the /etc/fstab file. It means: /dev/device-mapper/foo /bar ext2 noauto,user > /etc/crypttab: > foo /dev/sdc1 none cipher=twofish-cbc-plain,size=256,hash=sha512,itercountk=100,noauto We need a way how easily extend mount process by arbitrary functionality. There is not dm-crypt only. We have also classic loop, dm-loop and I'm almost sure that we will see more scenarios where a device must be initialized before mount(2) and deinitialized after umount(2). After util-linux-ng 2.13 release I'd like to continue to work on libmount (http://hosted.fedoraproject.org/projects/libmount) The libmount will be a modular library where things like NFS, LUKS, ... are deployed to modules. > mount would then call "/sbin/crypttabhelper /dev/sdc1". The helper > parses /etc/crypttab, sets up the device mapper target and prints > the created block device to stdout, for example /dev/mapper/foo. > mount then actually needs to mount /dev/mapper/foo instead of > /dev/sdc1. Ie quite similar to how the loop option works. Maybe there is a way how implement it more transparently and without an extra option. mount /bar identification --> libblkid/libvolume_id --> fstype=LUKS initialization --> dlopen(/lib/mount/mnt-luks.so) --> read /etc/crypttab --> create /dev/device-mapper/foo re-identification --> fstype=ext3 mount --> mount(/dev/device-mapper/foo, /bar, ext3, 0, NULL) > Does anyone have an opinion on that? Does any distro maybe already > ship with a method to allow unprivileged user to manually setup and > mount dm-crypt stuff? Many people (for example around Fedora, see fedora-devel list archive) are waiting for a filesystem with a cryptographic support -- this thing is more useful in some scenarios than dm-crypt. The dm-crypt is very nice solution for swap area or laptops where you need fully encrypted devices. I don't think that there is any distribution with something better than workarounds for /etc/{fstab,crypttab}. Karel -- Karel Zak <kzak@xxxxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
