Re: [PATCH v3 03/10] util: Add 'usage' for encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 06/25/2016 01:27 AM, Ján Tomko wrote:
> On Fri, Jun 24, 2016 at 04:53:32PM -0400, John Ferlan wrote:
>> In order to use more common code and set up for a future type, modify the
>> encryption secret to allow the "usage" attribute or the "uuid" attribute
>> to define the secret. The "usage" in the case of a volume secret would be
>> the path to the volume.
> 
> s/would/could/?
> 
> IIUC it can be an arbitrary string.
> 

In 3 out of the 4 cases, I agree; however, for qcow storage encryption,
sadly it's the path to the volume, see virStorageGenerateQcowEncryption:

    def->usage_type = VIR_SECRET_USAGE_TYPE_VOLUME;
    if (VIR_STRDUP(def->usage.volume, vol->target.path) < 0)
        goto cleanup;

This then would be carried over into virSecretObjListFindByUsageLocked
where it searches through the secret objects comparing the 'value':

   <secret...
     <usage ...>
       <{volume, name, target, name}>value</{}>

with the usage 'value' here:

   <auth...> or <encryption...>
     <secret type='{passphrase|ceph|iscsi|passphrase}' usage='value'/>

(FYI: the on list TLS/TCP will have <serial type='tcp'> for <secret>)

So for qcow disk encryption one has:

<disk...>
  ...
  <source file='$path'>
  <driver name='qemu' type='{qcow|qcow2}'/>
  ...
  <encryption>
    <secret type='passphrase' {uuid,usage}='$string'/>
  </encryption>
  ...
</disk>

TBH: I suppose we "could" change that to be "any" string, but since this
type of secret is not useful, it's probably not worth the effort.

I added the usage field for two reasons #1 a comment in some changes a
while back that we should try to use virSecretGetSecretString for all
callers instead of conn->secretDriver->secretGetValue and #2 since I was
going to reuse the <encryption> for <driver name='qemu' type='luks'/>
processing and I wanted to be able to allow someone to provide
"whatever" string they wanted there.

I will adjust the commit message to provide details as to why for this
one type of usage model it's the volume name.

John
>>
>> This code will make use of the virSecretLookup{Parse|Format}Secret
>> common code.
>>
>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
>> ---
>> docs/formatstorageencryption.html.in               | 12 +++++---
>> docs/schemas/storagecommon.rng                     | 11 +++++--
>> src/qemu/qemu_process.c                            | 13 +++-----
>> src/storage/storage_backend.c                      |  3 +-
>> src/storage/storage_backend_fs.c                   |  3 +-
>> src/util/virstorageencryption.c                    | 26 ++++++----------
>> src/util/virstorageencryption.h                    |  3 +-
>> .../qemuxml2argv-encrypted-disk-usage.args         | 24 +++++++++++++++
>> .../qemuxml2argv-encrypted-disk-usage.xml          | 36
>> ++++++++++++++++++++++
>> tests/qemuxml2argvtest.c                           |  1 +
>> .../qemuxml2xmlout-encrypted-disk-usage.xml        |  1 +
>> tests/qemuxml2xmltest.c                            |  1 +
>> 12 files changed, 98 insertions(+), 36 deletions(-)
>> create mode 100644
>> tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk-usage.args
>> create mode 100644
>> tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk-usage.xml
>> create mode 120000
>> tests/qemuxml2xmloutdata/qemuxml2xmlout-encrypted-disk-usage.xml
>>
> 
> ACK
> 
> Jan

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]