similar to: [PATCH 1/2] options: Fixes and enhancements to --key parsing.

v1: https://www.redhat.com/archives/libguestfs/2019-November/msg00036.html

On Tuesday, 12 November 2019 19:35:12 CET Richard W.M. Jones wrote: > This allows multiple --key parameters on the command line to match a > single device. This could either be specified as: > > tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2 > > which would try "trykey1" and "trykey2" against /dev/sda1. This seems OK for me, so you can

This allows multiple --key parameters on the command line to match a single device. This could either be specified as: tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2 which would try "trykey1" and "trykey2" against /dev/sda1. And/or you can specify default keys which are tried against each device (after more specific keys fail), eg: tool --key

Hi, the following series adds a --key option in the majority of tools: this makes it possible to pass LUKS credentials programmatically, avoid the need to manually input them, or unsafely pass them via stdin. Thanks, Pino Toscano (2): mltools: create a cmdline_options struct Introduce a --key option in tools that accept keys builder/cmdline.ml | 2 +-

This combined patch series enables to decrypt LUKS devices on inspection by allowing the UUID of the LUKS device with the --key syntax. I opted for reusing the option instead of adding another one, as I think that device names and UUIDs are different enough that can be properly distinguished. A test for this (patch #4) can be applied only when the patches for common are applied, and the

This allows multiple --key parameters on the command line to match a single device. For example: tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2 would try "trykey1" and "trykey2" against /dev/sda1. --- options/decrypt.c | 41 ++++++++++++++++++++++++++++++++--------- options/keys.c | 45 +++++++++++++++++++++++++++++++++++---------- options/options.h | 6

On Tuesday, 26 November 2019 17:40:47 CET Richard W.M. Jones wrote: > This allows multiple --key parameters on the command line to match a > single device. For example: > > tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2 > > would try "trykey1" and "trykey2" against /dev/sda1. > --- Mostly LGTM, just one note/question below. > +

You can specify default keys which are tried against each device (after more specific keys fail), eg: tool --key :key:defaultkey1 --key :key:defaultkey2 which would try "defaultkey1" and "defaultkey2" against all devices in the guest. --- options/keys.c | 3 ++- options/options.h | 5 ++++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/options/keys.c

On Fri, Nov 15, 2019 at 03:23:02PM +0100, Pino Toscano wrote: > On Tuesday, 12 November 2019 19:35:12 CET Richard W.M. Jones wrote: > > This allows multiple --key parameters on the command line to match a > > single device. This could either be specified as: > > > > tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2 > > > > which would try

Hi Rich and Pino, Commenting after a test. I've installed a RHEL 7 virtual machine with 2 disks, using the graphical installer. During the installation, I selected the 2 disks as well as encryption checkbox. It asked me for only one password. After the installation, when the machine boots, it asks for the password (showing a device UUID) only once. When connected as root, I can see that there

The majority of the tools have already options (--echo-keys & --keys-from-stdin) to deal with LUKS credentials, although there is no way to automatically provide credentials. --keys-from-stdin is suboptimal, because it is an usable solution only when there is just one device to open, and no other input passed via stdin to the tool (like the commands for guestfish). To overcome this

Easily reproducible using: $ guestfish --key dev1:key:key1 --key dev2:key:key2 causing this stack trace (or others depending on where the memory corruption was caught): Program received signal SIGABRT, Aborted. 0x00007ffff7905625 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff7905625 in raise () from /lib64/libc.so.6 #1 0x00007ffff78ee8d9 in abort () from

On Saturday, 16 November 2019 09:33:21 CET Richard W.M. Jones wrote: > On Fri, Nov 15, 2019 at 03:23:02PM +0100, Pino Toscano wrote: > > On Tuesday, 12 November 2019 19:35:12 CET Richard W.M. Jones wrote: > > > This allows multiple --key parameters on the command line to match a > > > single device. This could either be specified as: > > > > > >

The following patch attempts to implement sparsification of LUKS-encrypted partitions. It uses lsblk to pair the underlying LUKS block device with its mapped name. Also, --allow-discards was added by default to luks_open(). There are several potential issues that I can think of: 1) If and entire device is encrypted (not just one of more partitions), the lsblk trick might not work. 2) The

Refactor this code to use guestfs_int_split_string function which slightly simplifies it. This should have no effect. --- options/keys.c | 35 ++++++++++++++--------------------- 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/options/keys.c b/options/keys.c index f783066..74b5497 100644 --- a/options/keys.c +++ b/options/keys.c @@ -153,49 +153,42 @@ get_key (struct key_store

This way it is possible to specify the UUID of the LUKS device instead of the libguestfs device name to decrypt a device during the inspection. Make the usage of the new luks_uuid API conditional, so other projects using the common submodule do not require a libguestfs version bump. --- options/decrypt.c | 8 +++++++- options/key-option.pod | 4 ++-- options/keys.c | 4 ++--

In the future it will be also something else other than the device name. --- mltools/tools_utils-c.c | 4 ++-- options/key-option.pod | 7 ++++--- options/keys.c | 8 ++++---- options/options.h | 8 +++++--- 4 files changed, 15 insertions(+), 12 deletions(-) diff --git a/mltools/tools_utils-c.c b/mltools/tools_utils-c.c index 3b80091..6c43b8d 100644 --- a/mltools/tools_utils-c.c

Enhance the output in machine parseable mode, by outputting all the messages of OCaml tools as JSON to the machine parseable stream. Related, although not strictly needed for this (and thus can be split if requested), is the addition of the fd format for the machine readable stream. Pino Toscano (4): common/mltools: move the code for machine readable up common/mltools: make sure machine

Enhance the output in machine parseable mode, by outputting all the messages of OCaml tools as JSON to the machine parseable stream. Related, although not strictly needed for this (and thus can be split if requested), is the addition of the fd format for the machine readable stream. Changes from v1: - use Obj.magic to convert int -> Unix.file_descr - add tests Pino Toscano (4):

On Wed, Jan 22, 2020 at 10:14:38AM +0100, Jan Synacek wrote: > -val inspect_decrypt : Guestfs.guestfs -> key_store -> unit > +val inspect_decrypt : Guestfs.guestfs -> ?allow_discards:bool -> key_store -> unit > > (** Simple implementation of decryption: look for any [crypto_LUKS] > partitions and decrypt them, then rescan for VGs. This only works > for