Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Thu, 23.04.15 21:04, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 23 April 2015 at 13:08, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote: What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Well, we might as well implement this in the most obvious way if it is not a completely standard feature yet. To me it appears that only one initrd supported it, and it lost it a while back without too much complaining... But anyway, I don't mind too much. The debian's initramfs-tools, but not ubuntu's, support keyfile on usb-disk for unlocking luks volumes. the exact name of the option and semantics to specify it to initramfs-tools is different from dracut's (but that's typical) but said equivalent feature does exist in the major other initramfs implementation. What's the syntax of Debian's initrd for this? I mean, if their syntax makes more sense, we might standardise on theirs... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Fri, 24.04.15 09:05, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? Hi, I can see that Andrei already answered most of your questions. Some time after writing this patch, I realized that I should just fix dracut, so I did [1], and I forgot to leave a mention in this thread. I'm not sure what happened to the dracut patch since then, though. [1] http://thread.gmane.org/gmane.linux.kernel.initramfs/4072 I think the basic feature set of dracut that we can neatly support directly in systemd's generators we should support there. But of course, the question is whether this is a basic feature or not. Anyway, the offer still stands, for merging something like this, see other mail. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Fri, 24.04.15 13:37, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: the exact name of the option and semantics to specify it to initramfs-tools is different from dracut's (but that's typical) but said equivalent feature does exist in the major other initramfs implementation. What's the syntax of Debian's initrd for this? I mean, if their syntax makes more sense, we might standardise on theirs... So in debian this is done via keyscript argument in /etc/crypttab, and there is passdev keyscript provided by the package that is typically used. initramfs-tools hooks copy all of those into initramfs. The passdev is a C binary that takes a single argument - device:filepath[:timeout] The binary waits for the device to appear (infinity or up to optionally specified time-out parameter), mounts it read-only, and read the filepath to attempt luks unlock for the device specified in the crypttab. See docs and sources at: https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/README.Debian/#L139 https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/passdev.c/ I am indifferent about configuration done via keyscript= parameter in crypttab, the quality of the passdev implementation. But the device:filepath[:timeout] argument format is imho a simple sensible one for this. There are a bunch of other keyscript= binaries provided for remote unlocking over ssh, smartcards, yubikeys and so on, because debian supports arbitrary things there. A lot of the times people write their own keyscript by hand for their usecases. =) as usual debian prefers arbitrary code execution instead of something rigidly declarative ;-) I am very very un-enthusiastic about the keyscript does. I don't want to see this upstream. For yubikeys/smartcards I am pretty sure proper support should be added to the c tools, not via some script glue. I think DEbian's argument with device before file path certainly makes more sense, but ultimately I don't really care about the order. WOuld still be willing to add a patch that adds support for such external keys. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On 24 April 2015 at 10:06, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 21:04, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 23 April 2015 at 13:08, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote: What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Well, we might as well implement this in the most obvious way if it is not a completely standard feature yet. To me it appears that only one initrd supported it, and it lost it a while back without too much complaining... But anyway, I don't mind too much. The debian's initramfs-tools, but not ubuntu's, support keyfile on usb-disk for unlocking luks volumes. the exact name of the option and semantics to specify it to initramfs-tools is different from dracut's (but that's typical) but said equivalent feature does exist in the major other initramfs implementation. What's the syntax of Debian's initrd for this? I mean, if their syntax makes more sense, we might standardise on theirs... So in debian this is done via keyscript argument in /etc/crypttab, and there is passdev keyscript provided by the package that is typically used. initramfs-tools hooks copy all of those into initramfs. The passdev is a C binary that takes a single argument - device:filepath[:timeout] The binary waits for the device to appear (infinity or up to optionally specified time-out parameter), mounts it read-only, and read the filepath to attempt luks unlock for the device specified in the crypttab. See docs and sources at: https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/README.Debian/#L139 https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/passdev.c/ I am indifferent about configuration done via keyscript= parameter in crypttab, the quality of the passdev implementation. But the device:filepath[:timeout] argument format is imho a simple sensible one for this. There are a bunch of other keyscript= binaries provided for remote unlocking over ssh, smartcards, yubikeys and so on, because debian supports arbitrary things there. A lot of the times people write their own keyscript by hand for their usecases. =) as usual debian prefers arbitrary code execution instead of something rigidly declarative ;-) -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
Lennart Poettering lenn...@poettering.net writes: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? Hi, I can see that Andrei already answered most of your questions. Some time after writing this patch, I realized that I should just fix dracut, so I did [1], and I forgot to leave a mention in this thread. I'm not sure what happened to the dracut patch since then, though. [1] http://thread.gmane.org/gmane.linux.kernel.initramfs/4072 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
В Thu, 23 Apr 2015 16:57:09 +0200 Lennart Poettering lenn...@poettering.net пишет: On Thu, 23.04.15 06:41, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 23 Apr 2015 00:48:38 +0200 Lennart Poettering lenn...@poettering.net пишет: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? There are multiple bug reports that switching to dracut with integrated systemd breaks ability to auto-setup encrypted devices using keyfile on external USB stick. Hmm, but from Jan's mail I got the impression that this is a Dracut feature in the first place? Now I am confused? Which initrd implementations supported this scheme before? Dracut supported it. When it implemented native systemd in intird, it lost this feature. You can get it back building initrd without systemd dracut module. What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? Sure, in dracut manual page: crypto LUKS - key on removable device support rd.luks.key=keypath:keydev:luksdev keypath is a path to key file to look for. It’s REQUIRED. When keypath ends with .gpg it’s considered to be key encrypted symmetrically with GPG. You will be prompted for password on boot. GPG support comes with crypt-gpg module which needs to be added explicitly. keydev is a device on which key file resides. It might be kernel name of devices (should start with /dev/), UUID (prefixed with UUID=) or label (prefix with LABEL=). You don’t have to specify full UUID. Just its beginning will suffice, even if its ambiguous. All matching devices will be probed. This parameter is recommended, but not required. If not present, all block devices will be probed, which may significantly increase boot time. If luksdev is given, the specified key will only be applied for that LUKS device. Possible values are the same as for keydev. Unless you have several LUKS devices, you don’t have to specify this parameter. The simplest usage is: Example. rd.luks.key=/foo/bar.key As you see, you can skip colons in such a case. First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? To fetch keyfile dracut needs to mount USB stick. This mount is not normally needed after cryptomount setup is completed. Well, sure, I am just wondering what precisely shall be used as trigger to unmount it again. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Thu, 23.04.15 06:41, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 23 Apr 2015 00:48:38 +0200 Lennart Poettering lenn...@poettering.net пишет: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? There are multiple bug reports that switching to dracut with integrated systemd breaks ability to auto-setup encrypted devices using keyfile on external USB stick. Hmm, but from Jan's mail I got the impression that this is a Dracut feature in the first place? Now I am confused? Which initrd implementations supported this scheme before? What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? To fetch keyfile dracut needs to mount USB stick. This mount is not normally needed after cryptomount setup is completed. Well, sure, I am just wondering what precisely shall be used as trigger to unmount it again. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote: What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Well, we might as well implement this in the most obvious way if it is not a completely standard feature yet. To me it appears that only one initrd supported it, and it lost it a while back without too much complaining... But anyway, I don't mind too much. The Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? Sure, in dracut manual page: crypto LUKS - key on removable device support rd.luks.key=keypath:keydev:luksdev keypath is a path to key file to look for. It’s REQUIRED. When keypath ends with .gpg it’s considered to be key encrypted symmetrically with GPG. You will be prompted for password on boot. GPG support comes with crypt-gpg module which needs to be added explicitly. To make this clear: the gpg support is crazy. I don't want to see that in systemd at all. Also, so far we don't allow luksdev to be specified for any of the other options, such as luks.options or so. I am not convinced we should support that here. I'd be willing to merge a patch that supports basic rd.luks.key=keypath:keydev, even though I think it's usecase is more security theater than really useful. But please put the temporary mount into /run, keep it minimal, define a clear trigger to unmount it, no gpg, no luksdev support. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On 23 April 2015 at 13:08, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote: What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Well, we might as well implement this in the most obvious way if it is not a completely standard feature yet. To me it appears that only one initrd supported it, and it lost it a while back without too much complaining... But anyway, I don't mind too much. The debian's initramfs-tools, but not ubuntu's, support keyfile on usb-disk for unlocking luks volumes. the exact name of the option and semantics to specify it to initramfs-tools is different from dracut's (but that's typical) but said equivalent feature does exist in the major other initramfs implementation. Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? Sure, in dracut manual page: crypto LUKS - key on removable device support rd.luks.key=keypath:keydev:luksdev keypath is a path to key file to look for. It’s REQUIRED. When keypath ends with .gpg it’s considered to be key encrypted symmetrically with GPG. You will be prompted for password on boot. GPG support comes with crypt-gpg module which needs to be added explicitly. To make this clear: the gpg support is crazy. I don't want to see that in systemd at all. Also, so far we don't allow luksdev to be specified for any of the other options, such as luks.options or so. I am not convinced we should support that here. I'd be willing to merge a patch that supports basic rd.luks.key=keypath:keydev, even though I think it's usecase is more security theater than really useful. But please put the temporary mount into /run, keep it minimal, define a clear trigger to unmount it, no gpg, no luksdev support. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? What does this actually do? Is the specified key file read from the specified device? The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? Is this specific to Dracut so far? Is this widely used, and something that we really want. First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Things like this are necessarily racy: at boot time devices are not probed yet, and just start to appear. That means if you enumerate them it is highly likely your block device has not shown up yet, but will so shortly. Hence you need to wait for them. But that means you cannot really distuingish the case not shown up yet, but will from will never show up... Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Which is? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
В Thu, 23 Apr 2015 00:48:38 +0200 Lennart Poettering lenn...@poettering.net пишет: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? There are multiple bug reports that switching to dracut with integrated systemd breaks ability to auto-setup encrypted devices using keyfile on external USB stick. What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). In any case it became dracut API which is too late to change. Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? To fetch keyfile dracut needs to mount USB stick. This mount is not normally needed after cryptomount setup is completed. Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Things like this are necessarily racy: at boot time devices are not probed yet, and just start to appear. That means if you enumerate them it is highly likely your block device has not shown up yet, but will so shortly. Hence you need to wait for them. But that means you cannot really distuingish the case not shown up yet, but will from will never show up... Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Which is? LUKS device to which key applies. Can be wildcarded. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
Andrei Borzenkov arvidj...@gmail.com writes: В Fri, 20 Feb 2015 10:56:41 +0100 Jan Synacek jsyna...@redhat.com пишет: First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. This sounds like working around dracut bug. Dracut already has code to deal with it, it updates /etc/crypttab and reload systemd to run generators but it completely ignores keyfile parameter in non-systemd branch. The code in dracut for systemd-enabled case does echo $luks $dev - timeout=0,$allowdiscards /etc/crypttab systemctl daemon-reload systemctl start cryptsetup.target which means it won't even use keyfile anyway. Why do not you simply mount device here? Dracut already has code to temporary mount keyfile device in non-systemd-enabled case, you can simply reuse it. I've done some digging around and... I don't get it. It makes sense to put the functionality to dracut, so why is this implemented *differently* in both dracut and systemd? Why is there code to make this systemd-independent task in a systemd-enabled and non-systemd-enabled case? It's quite confusing. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? Dracut creates unique name for it already. Ok, I found the code. Thanks for the pointers! Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Jan Synacek (1): cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device src/cryptsetup/cryptsetup-generator.c | 163 +++--- 1 file changed, 150 insertions(+), 13 deletions(-) -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
Andrei Borzenkov arvidj...@gmail.com writes: В Fri, 20 Feb 2015 10:56:42 +0100 Jan Synacek jsyna...@redhat.com пишет: To be more consistent with how dracut parses rd.luks.key, it is now allowed to specified it in the format keyfile[:keyfile_device]. Should keyfile_device be provided, it needs to be in UUID=uuid-here format. Also, keyfile path is then treated relatively to the root of the keyfile device. What makes UUID special? Why it cannot be anything mount understands (like LABEL=..., /dev/disk/by-uuid/...). systemd already has code to resolve it. UUID uniquely identifies the device and is always there. AFAIK that is not true for LABEL. Supporting LABEL would complicate things and since I wasn't even sure if my solution was the way to go, I didn't bother with it. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
Right, not in the doc. In fedora it is used in: /usr/lib/dracut/modules.d/90crypt/parse-crypt.sh Simply a device timeout in seconds. On 02/20/2015 11:53 AM, Jan Synacek wrote: Przemyslaw Rudy pru...@o2.pl writes: Could you use the rd.luks.key.tout= instead of hardcoded JobTimeoutSec=30, as the dracut does? I didn't know about such parameter. In fact, I don't see it anywhere in dracut.cmdline(5). If it really exists and just isn't documented, then yes, it would probably make sense. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
Przemyslaw Rudy pru...@o2.pl writes: Could you use the rd.luks.key.tout= instead of hardcoded JobTimeoutSec=30, as the dracut does? I didn't know about such parameter. In fact, I don't see it anywhere in dracut.cmdline(5). If it really exists and just isn't documented, then yes, it would probably make sense. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
Could you use the rd.luks.key.tout= instead of hardcoded
JobTimeoutSec=30, as the dracut does?
On 02/20/2015 10:56 AM, Jan Synacek wrote:
To be more consistent with how dracut parses rd.luks.key, it is now
allowed to specified it in the format keyfile[:keyfile_device].
Should keyfile_device be provided, it needs to be in UUID=uuid-here
format. Also, keyfile path is then treated relatively to the root of the
keyfile device.
If no keyfile_device appears on the command line, keyfile is then
treated as an absolute path.
Examples:
rd.luks.key=/etc/key/secret-partition.key
The keyfile is treated as an absolute path.
rd.luks.key=/root.key:UUID=dead-beef
First, the device UUID=dead-beef is temporarily mounted in /mnt and the
absolute path to the keyfile is constructed as /mnt/root.key.
---
src/cryptsetup/cryptsetup-generator.c | 163
+++---
1 file changed, 150 insertions(+), 13 deletions(-)
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 05061c0..3590787 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -43,6 +43,12 @@ typedef struct crypto_device {
bool create;
} crypto_device;
+typedef struct key_device {
+const crypto_device *device;
+char *keyfile;
+char *name;
+} key_device;
+
static const char *arg_dest = /tmp;
static bool arg_enabled = true;
static bool arg_read_crypttab = true;
@@ -50,6 +56,39 @@ static bool arg_whitelist = false;
static Hashmap *arg_disks = NULL;
static char *arg_default_options = NULL;
static char *arg_default_keyfile = NULL;
+static key_device *arg_key_device = NULL;
+
+static char *crypt_service_name_build(const char *name)
+{
+_cleanup_free_ char *e = NULL;
+
+e = unit_name_escape(name);
+if (!e)
+return e;
+
+return unit_name_build(systemd-cryptsetup, e, .service);
+}
+
+static key_device *get_key_device(void)
+{
+key_device *d;
+
+if (arg_key_device)
+return arg_key_device;
+
+d = new0(struct key_device, 1);
+if (!d)
+return NULL;
+
+arg_key_device = d;
+return arg_key_device;
+}
+
+static void free_key_device(key_device *kd)
+{
+free(kd-keyfile);
+free(kd-name);
+}
static int create_disk(
const char *name,
@@ -77,11 +116,7 @@ static int create_disk(
return -EINVAL;
}
-e = unit_name_escape(name);
-if (!e)
-return log_oom();
-
-n = unit_name_build(systemd-cryptsetup, e, .service);
+n = crypt_service_name_build(name);
if (!n)
return log_oom();
@@ -233,6 +268,76 @@ static int create_disk(
return 0;
}
+static int create_temporary_mount(void)
+{
+_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *p = NULL, *n = NULL, *c = NULL, *wants_dir =
NULL, *to = NULL, *u = NULL;
+const char *m = mnt.mount;
+key_device *kd;
+
+kd = get_key_device();
+if (!kd)
+return log_oom();
+
+/* no uuid where we should search for the key was specified */
+if (!kd-name)
+return 0;
+
+
+if (!kd-device) {
+log_warning(No rd.luks.uuid specified. Can't generate a
temporary mount unit);
+return 0;
+}
+
+p = strjoin(arg_dest, /, m, NULL);
+if (!p)
+return log_oom();
+
+
+f = fopen(p, wxe);
+if (!f)
+return log_error_errno(errno, Failed to open %s: %m, p);
+
+fprintf(f, # Automatically generated by
systemd-cryptsetup-generator\n\n
+[Unit]\n
+Description=Temporary keyfile mount point.\n
+JobTimeoutSec=30\n);
+
+n = strjoin(luks-, kd-device-uuid, NULL);
+if (!n)
+return log_oom();
+
+c = crypt_service_name_build(n);
+if (!c)
+return log_oom();
+
+u = fstab_node_to_udev_node(kd-name);
+if (!u)
+return log_oom();
+
+fprintf(f, Before=%s\n\n
+[Mount]\n
+What=%s\n
+Where=/mnt\n,
+c, u);
+
+wants_dir = strjoin(arg_dest, /, c, .wants, NULL);
+if (!wants_dir)
+return log_oom();
+
+to = strjoin(wants_dir, /, m, NULL);
+if (!to)
+return log_oom();
+
+if (mkdir_safe(wants_dir, 0700, 0, 0) 0)
+log_error(Failed to create %s: %m, wants_dir);
+
+if (symlink(../mnt.mount, to) 0)
+return log_error_errno(errno, Failed to create symlink %s:
%m, to);
+
+return 0;
+}
[systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Jan Synacek (1): cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device src/cryptsetup/cryptsetup-generator.c | 163 +++--- 1 file changed, 150 insertions(+), 13 deletions(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
To be more consistent with how dracut parses rd.luks.key, it is now
allowed to specified it in the format keyfile[:keyfile_device].
Should keyfile_device be provided, it needs to be in UUID=uuid-here
format. Also, keyfile path is then treated relatively to the root of the
keyfile device.
If no keyfile_device appears on the command line, keyfile is then
treated as an absolute path.
Examples:
rd.luks.key=/etc/key/secret-partition.key
The keyfile is treated as an absolute path.
rd.luks.key=/root.key:UUID=dead-beef
First, the device UUID=dead-beef is temporarily mounted in /mnt and the
absolute path to the keyfile is constructed as /mnt/root.key.
---
src/cryptsetup/cryptsetup-generator.c | 163 +++---
1 file changed, 150 insertions(+), 13 deletions(-)
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 05061c0..3590787 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -43,6 +43,12 @@ typedef struct crypto_device {
bool create;
} crypto_device;
+typedef struct key_device {
+const crypto_device *device;
+char *keyfile;
+char *name;
+} key_device;
+
static const char *arg_dest = /tmp;
static bool arg_enabled = true;
static bool arg_read_crypttab = true;
@@ -50,6 +56,39 @@ static bool arg_whitelist = false;
static Hashmap *arg_disks = NULL;
static char *arg_default_options = NULL;
static char *arg_default_keyfile = NULL;
+static key_device *arg_key_device = NULL;
+
+static char *crypt_service_name_build(const char *name)
+{
+_cleanup_free_ char *e = NULL;
+
+e = unit_name_escape(name);
+if (!e)
+return e;
+
+return unit_name_build(systemd-cryptsetup, e, .service);
+}
+
+static key_device *get_key_device(void)
+{
+key_device *d;
+
+if (arg_key_device)
+return arg_key_device;
+
+d = new0(struct key_device, 1);
+if (!d)
+return NULL;
+
+arg_key_device = d;
+return arg_key_device;
+}
+
+static void free_key_device(key_device *kd)
+{
+free(kd-keyfile);
+free(kd-name);
+}
static int create_disk(
const char *name,
@@ -77,11 +116,7 @@ static int create_disk(
return -EINVAL;
}
-e = unit_name_escape(name);
-if (!e)
-return log_oom();
-
-n = unit_name_build(systemd-cryptsetup, e, .service);
+n = crypt_service_name_build(name);
if (!n)
return log_oom();
@@ -233,6 +268,76 @@ static int create_disk(
return 0;
}
+static int create_temporary_mount(void)
+{
+_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *p = NULL, *n = NULL, *c = NULL, *wants_dir =
NULL, *to = NULL, *u = NULL;
+const char *m = mnt.mount;
+key_device *kd;
+
+kd = get_key_device();
+if (!kd)
+return log_oom();
+
+/* no uuid where we should search for the key was specified */
+if (!kd-name)
+return 0;
+
+
+if (!kd-device) {
+log_warning(No rd.luks.uuid specified. Can't generate a
temporary mount unit);
+return 0;
+}
+
+p = strjoin(arg_dest, /, m, NULL);
+if (!p)
+return log_oom();
+
+
+f = fopen(p, wxe);
+if (!f)
+return log_error_errno(errno, Failed to open %s: %m, p);
+
+fprintf(f, # Automatically generated by
systemd-cryptsetup-generator\n\n
+[Unit]\n
+Description=Temporary keyfile mount point.\n
+JobTimeoutSec=30\n);
+
+n = strjoin(luks-, kd-device-uuid, NULL);
+if (!n)
+return log_oom();
+
+c = crypt_service_name_build(n);
+if (!c)
+return log_oom();
+
+u = fstab_node_to_udev_node(kd-name);
+if (!u)
+return log_oom();
+
+fprintf(f, Before=%s\n\n
+[Mount]\n
+What=%s\n
+Where=/mnt\n,
+c, u);
+
+wants_dir = strjoin(arg_dest, /, c, .wants, NULL);
+if (!wants_dir)
+return log_oom();
+
+to = strjoin(wants_dir, /, m, NULL);
+if (!to)
+return log_oom();
+
+if (mkdir_safe(wants_dir, 0700, 0, 0) 0)
+log_error(Failed to create %s: %m, wants_dir);
+
+if (symlink(../mnt.mount, to) 0)
+return log_error_errno(errno, Failed to create symlink %s:
%m, to);
+
+return 0;
+}
+
static void free_arg_disks(void) {
crypto_device *d;
@@ -282,6 +387,7 @@ static crypto_device *get_crypto_device(const char *uuid) {
static int parse_proc_cmdline_item(const char *key, const char *value) {
int r;
crypto_device *d;
+key_device *kd;
_cleanup_free_
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Fri, Feb 20, 2015 at 11:15:36AM +0100, Przemyslaw Rudy wrote:
Could you use the rd.luks.key.tout= instead of hardcoded
JobTimeoutSec=30, as the dracut does?
Maybe we could rename it to rd.luks.key.device-timeout= ? tout is not
really descriptive. (Old name should be kept for comptibility, the new
one should be documented.)
Zbyszek
On 02/20/2015 10:56 AM, Jan Synacek wrote:
To be more consistent with how dracut parses rd.luks.key, it is now
allowed to specified it in the format keyfile[:keyfile_device].
Should keyfile_device be provided, it needs to be in UUID=uuid-here
format. Also, keyfile path is then treated relatively to the root of the
keyfile device.
If no keyfile_device appears on the command line, keyfile is then
treated as an absolute path.
Examples:
rd.luks.key=/etc/key/secret-partition.key
The keyfile is treated as an absolute path.
rd.luks.key=/root.key:UUID=dead-beef
First, the device UUID=dead-beef is temporarily mounted in /mnt and the
absolute path to the keyfile is constructed as /mnt/root.key.
---
src/cryptsetup/cryptsetup-generator.c | 163
+++---
1 file changed, 150 insertions(+), 13 deletions(-)
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 05061c0..3590787 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -43,6 +43,12 @@ typedef struct crypto_device {
bool create;
} crypto_device;
+typedef struct key_device {
+const crypto_device *device;
+char *keyfile;
+char *name;
+} key_device;
+
static const char *arg_dest = /tmp;
static bool arg_enabled = true;
static bool arg_read_crypttab = true;
@@ -50,6 +56,39 @@ static bool arg_whitelist = false;
static Hashmap *arg_disks = NULL;
static char *arg_default_options = NULL;
static char *arg_default_keyfile = NULL;
+static key_device *arg_key_device = NULL;
+
+static char *crypt_service_name_build(const char *name)
+{
+_cleanup_free_ char *e = NULL;
+
+e = unit_name_escape(name);
+if (!e)
+return e;
+
+return unit_name_build(systemd-cryptsetup, e, .service);
+}
+
+static key_device *get_key_device(void)
+{
+key_device *d;
+
+if (arg_key_device)
+return arg_key_device;
+
+d = new0(struct key_device, 1);
+if (!d)
+return NULL;
+
+arg_key_device = d;
+return arg_key_device;
+}
+
+static void free_key_device(key_device *kd)
+{
+free(kd-keyfile);
+free(kd-name);
+}
static int create_disk(
const char *name,
@@ -77,11 +116,7 @@ static int create_disk(
return -EINVAL;
}
-e = unit_name_escape(name);
-if (!e)
-return log_oom();
-
-n = unit_name_build(systemd-cryptsetup, e, .service);
+n = crypt_service_name_build(name);
if (!n)
return log_oom();
@@ -233,6 +268,76 @@ static int create_disk(
return 0;
}
+static int create_temporary_mount(void)
+{
+_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *p = NULL, *n = NULL, *c = NULL, *wants_dir =
NULL, *to = NULL, *u = NULL;
+const char *m = mnt.mount;
+key_device *kd;
+
+kd = get_key_device();
+if (!kd)
+return log_oom();
+
+/* no uuid where we should search for the key was specified */
+if (!kd-name)
+return 0;
+
+
+if (!kd-device) {
+log_warning(No rd.luks.uuid specified. Can't generate a
temporary mount unit);
+return 0;
+}
+
+p = strjoin(arg_dest, /, m, NULL);
+if (!p)
+return log_oom();
+
+
+f = fopen(p, wxe);
+if (!f)
+return log_error_errno(errno, Failed to open %s: %m, p);
+
+fprintf(f, # Automatically generated by
systemd-cryptsetup-generator\n\n
+[Unit]\n
+Description=Temporary keyfile mount point.\n
+JobTimeoutSec=30\n);
+
+n = strjoin(luks-, kd-device-uuid, NULL);
+if (!n)
+return log_oom();
+
+c = crypt_service_name_build(n);
+if (!c)
+return log_oom();
+
+u = fstab_node_to_udev_node(kd-name);
+if (!u)
+return log_oom();
+
+fprintf(f, Before=%s\n\n
+[Mount]\n
+What=%s\n
+Where=/mnt\n,
+c, u);
+
+wants_dir = strjoin(arg_dest, /, c, .wants, NULL);
+if (!wants_dir)
+
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
В Fri, 20 Feb 2015 10:56:42 +0100 Jan Synacek jsyna...@redhat.com пишет: To be more consistent with how dracut parses rd.luks.key, it is now allowed to specified it in the format keyfile[:keyfile_device]. Should keyfile_device be provided, it needs to be in UUID=uuid-here format. Also, keyfile path is then treated relatively to the root of the keyfile device. What makes UUID special? Why it cannot be anything mount understands (like LABEL=..., /dev/disk/by-uuid/...). systemd already has code to resolve it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
В Fri, 20 Feb 2015 10:56:41 +0100 Jan Synacek jsyna...@redhat.com пишет: First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. This sounds like working around dracut bug. Dracut already has code to deal with it, it updates /etc/crypttab and reload systemd to run generators but it completely ignores keyfile parameter in non-systemd branch. The code in dracut for systemd-enabled case does echo $luks $dev - timeout=0,$allowdiscards /etc/crypttab systemctl daemon-reload systemctl start cryptsetup.target which means it won't even use keyfile anyway. Why do not you simply mount device here? Dracut already has code to temporary mount keyfile device in non-systemd-enabled case, you can simply reuse it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? Dracut creates unique name for it already. Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Jan Synacek (1): cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device src/cryptsetup/cryptsetup-generator.c | 163 +++--- 1 file changed, 150 insertions(+), 13 deletions(-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
В Fri, 20 Feb 2015 12:20:09 +0100 Przemyslaw Rudy pru...@o2.pl пишет: Right, not in the doc. In fedora it is used in: /usr/lib/dracut/modules.d/90crypt/parse-crypt.sh It is also upstream. Simply a device timeout in seconds. On 02/20/2015 11:53 AM, Jan Synacek wrote: Przemyslaw Rudy pru...@o2.pl writes: Could you use the rd.luks.key.tout= instead of hardcoded JobTimeoutSec=30, as the dracut does? I didn't know about such parameter. In fact, I don't see it anywhere in dracut.cmdline(5). If it really exists and just isn't documented, then yes, it would probably make sense. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
