On Mon, Jul 09, 2012 at 10:49:56PM +0200, Lennart Poettering wrote: >On Fri, 29.06.12 00:56, David Härdeman (da...@hardeman.nu) wrote: > >> Debian's cryptsetup package supports the keyscript= option in /etc/crypttab >> >> This patch is a first attempt at implementing support for the same option >> in systemd. It is not at exact feature parity yet (environment variables >> are missing and relative paths are not supported), but it's a start. >> >> I'm not sure if the (somewhat complicated dance) with fds is considered >> acceptable or if I should use something else? > >Humpf. So I am really not convinced that supporting this is really such >a good idea. I am not a fan at all of this scriptlogic. (Starting with >the fact that this is called keyscript=, i.e. as if this really needs to >be a script...).
The name of the option (keyscript) doesn't mean that it needs to be e.g. a bash script, it could be any executable. >I wonder what the precise usecases for this are, and whether we can't >find better solutions for these usecases... I originally implemented the keyscript= support in Debian, and the way I see it there are two different usecases depending on your point of view. As a package maintainer, or in this case systemd maintainer, the keyscript= functionality was a good way of keeping bloat out of the cryptsetup scripts (granted, some would probably say that the cryptsetup scripts in Debian are already bloated, but without this functionality they would be even more so). Whenever a user comes up with another scheme for storing keys (you've already seen some...like storing keys between the MBR and first partition using the keyfile-offset= parameter), it is possible to ask them to use a keyscript= instead of extending the cryptsetup logic. >From a user point of view it is of course additional flexibility which is the usecase. I've seen keyscripts to use Yubikeys, keyscripts to get keys off a smartcard (and the PIN for the smartcard could be requested via systemd passwordagents or any other scheme), scripts which mount different filesystems and grab the key off them, etc. But yes, it might of course be possible to find a "better" (non-backwards-compatible) solution. Starting with introducing support for binary strings in PasswordAgents (see below). >I mean, we already have the password agent logic, that is asynchronous, >and way more powerful: > >http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents I also dislike additional complexity and realize that systemd is an excellent oppurtinity of providing some much needed spring cleaning in distribution-specific boot scripts - but there are a few problems with using password agents: 1) Backwards compatibility "keyscript" has been supported by the Debian cryptsetup package for a long time and people already have keyscripts. Some of these are used for boot-critical partitions. Just telling everyone to rewrite whatever they have as passwordagents is unlikely to be accepted. 2) PasswordAgents can't handle binary strings keyscripts typically generate the key for the device and pass it to stdout. PasswordAgents can't handle binary strings which contain NUL characters (for example). 3) systemd specific solution Converting keyscript= scripts to password agents introduce a strong dependency on systemd. I realize that you don't consider it to be a problem but I'm guessing it wouldn't be acceptable to Debian (where systemd is not mandatory). -- David Härdeman _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel