* On Monday, 24 March 2014 23:24, Lennart Poettering <lenn...@poettering.net> wrote: > > No grokking what this is about really? What do you need the param for, > why isn't the existing agent logic good enough for this? Do you need > some identifier to pass across, or what is supposed to be included > there? >
The goal here is to be able to reuse "handlers" that have been developed for Debian. The original "keyscript" options comes from them and this implementation uses the "key_file" field of the crypttab as an argument to the "keyscript". This "key_file" does not have necessary to be a real "key_file". For instance, you could have something like that in your crypttab: crypt1 /dev/sda UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,FILE=toto.key luks,keyscript=/usr/bin/mykeyscript crypt2 /dev/sdb UUID=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy,FILE=tata.key luks,keyscript=/usr/bin/mykeyscript So here we use the same "keyscript" with a variable key_file located on different devices. Another usecase might be to have a keyscript that ask for a vocal passphrase, and the compares the vocal signature with a database that might be different from one device to another. > Supporting an automatic fallback to asking for a password interactively > when a file doesn't exist on disk is something we should anyway do in > systemd-cryptsetup, this shouldn#t need any special scrip hookup. (Note > however that we nowadays add RequiresMountsFor= for the file specified > in cryptsetup so that we'll wait for any USB disk mentioned therein > anyway, which means we'd delay the cryptsetup logic untilt he device has > shown up.) Well that's exactly what the patch does. The fallback IS in systemd-cryptsetup. But that should probably be enhanced. It would also be good if we could spawn another agent from an agent. For example if our keyfile is encrypted via GPG, we could be able to ask the GPG passphrase from another agent so that our "main" agent can decrypt the keyfile and then decrypt the device. > > But anyway, for this specific usecase, I'd really like to see a patch > for systemd that makes this standard behaviour. > > Well, firstly, I'd have to udnerstand the concept. ;-) > > Also, all patches need to be submitted against systemd git... > Thanks -- Benjamin SANS
signature.asc
Description: Digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
