On Mon, Nov 18, 2019 at 12:11:15PM +0100, Pino Toscano wrote:
On Saturday, 16 November 2019 09:33:21 CET Richard W.M. Jones wrote:
> It's considerably more convenient for callers if they don't have to
> store this mapping between opaque libguestfs device names (a concept
> which is meaningless to most users and to the software which
> orchestrates virt-v2v at scale), and keys.
We use devices already for various things, including partitions and
(in this case) devices for keys. If you use libguestfs tools (virt-v2v
included) then you need to care about them, so "callers are dumb" is
not one of the best arguments you can come up with.
In practical terms this would mean IMS has to do a new round trip
where we would have to do libguestfs inspection on guests before they
are presented in the UI, which is a whole bunch of work, and I still
don't understand why this would be necessary.
> Also there's no actual penalty to making this feature
available, it's
> a natural extension which falls out from the implementation, and it
> doesn't affect performance unless the caller adds multiple --key
> parameters. It's also how LUKS itself works if you enable
> decrypt_keyctl in crypttab.
This is not about performance or how LUKS works (which both are
irrelevant for libguestfs users), but rather about explicitly specifying
a secret only to its target.
In the case where you run virt-v2v --key --key ... then the secrets
are only passed to a single VM. So even if it was possible for the VM
to capture these keys, it would only be capturing keys used by its own
disks. I really don't understand what could be the problem with this.
> > Also, this makes it possible so
> > in case of two similar guests like:
> > - /dev/sda1 with key "key1", and /dev/sda2 with key "key2"
> > - /dev/sda1 with key "key2", and /dev/sda2 with key "key1"
> > the above command like will work in the same way, with no indication of
> > which key was successfully used for which device -- so you can silently
> > swap the first guest for the second with no changes to the v2v command
> > line...
>
> I didn't understand this. It seems an unlikely scenario in the first
> place, and has no ill effects even if it does occur.
I disagree with your assessment. Let's say that the first guest gets a
new encypted partition with coincidentally the same key as /dev/sda1:
I do not want that with a wildcard --key that device is silently opened
without the user acting and explicitly saying "this is the key for this
device" -- even if it is the same as another device.
OK so I believe you are worried that someone uses the same --key
option against two different guests. But how is that any different
from now? They could still accidentally reuse a key between guests
even the way it works right now.
In any case I don't understand how the guest could capture or save the
key, so I don't understand what the specific danger is.
> > What's the use case for this?
>
> So that IMS doesn't have to collect an exact mapping between opaque
> libguestfs device names and keys, which will require some user to have
> to enter device names that they don't understand into a UI without any
> making typos rather than just supplying a list of keys that apply to a
> single guest.
Few things here:
- if the UI does not help the user insert the proper mapping between
devices (which cloudforms already knows) and keys, then it's a
problem of the UI
The problem is cloudforms doesn't really know libguestfs device names.
It knows something about devices and partitions, but those are derived
from SSA not libguestfs.
- users can make typos even with your solution
If they typo the passphrase I guess everyone will expect it not to
work. The problem is if they typo "/dev/sda2" which they have no idea
about.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org