Quoting Herbert Valerio Riedel <hvr@xxxxxxxxxx>: > this looks a bit inconsistent, since the encryption algorithm is passed > as -o option, while the hashing filter is passed completely different; > one might really want to be able to specifiy the passphrase acquiring > plugin as fstab-option, in order to allow unattended automatic mounting > of fs volumes -- i.e. think of some executable/script that gathers the > passphrase from some removable media, that has to be inserted into the > system at boot-up time (e.g. smartcard, or even a plain old floppy disk) > > one might also want to be able to specify some options to pass to the > passphrase-acquiral executable; that way one doesn't have to install a > dozen of small binaries (or symlinks to the same one, and having to > discriminate on argv[0]), just have slightly different behaviours Sounds good. My thinking had been that the syntax should be as similar as possible to the syntax for specifying fd, since they conflict with each other. Also Andries has said that he's opposed to more "-o" type options (also evidenced by the fact that he turned "-o passfd=" into -p). > so the mount line above might look something like: > > mount -o > loop,encryption=aes-cbc- 128,key_exec=/sbin/get_and_hash_passphrase,key_args=sha256 > /home/sluskyb/testloop /mnt/testloop > > one could prepend some default arguments before the user-defined ones, > such as mountpoint, selected encryption algo/params (in order to allow > for more control about how to fill (or pad remaining) keybits) > > any comments? Or if Andries objects, I would propose cutting out the key_args option, instead using the default args you described and discriminating on argv[0]... - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
