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