Karel Zak wrote: > On Mon, Jun 18, 2007 at 05:36:31PM +0200, Ludwig Nussel wrote: > > 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 Makes sense for fsck but is inconvenient for loop devices. OTOH if dm-loop works there is probably no reason to use the old loop devices anymore. > > /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. Sounds good. > > 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) That squence only works for LUKS. Plain dm-crypt encrypted volumes cannot be identified, they appear to be random garbage so there needs to be an option that specifies a plugin. For LUKS /etc/crypttab isn't really needed anyways as LUKS metadata already contains all necessary parameters for decryption. > > 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. It would be nice to be able to mount encrypted images on demand as user nevertheless. Hmm, maybe I can abuse hal for that. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) - 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
