Differences to RFC:
http://www.redhat.com/archives/libvir-list/2016-March/msg00966.html
(many, but highlights are):
* Patch2 is Patch1 and I figured out the 'qom-list-types' magic in order
to fill in the .replies file
* Use of qemuDomainObjPrivate rather than passing 'masterKey'
* The masterKey is not stored in XML output nor is it stored as a
base64 value
* The masterKey is created during qemuProcessPrepareHost right after
the libDir is created. It is only created if the capability exists.
* The masterKey is removed during qemuProcessStop. There is no call
to qemuDomainMasterKeyRemove from qemuDomainObjPrivateFree since
the assumption is the *Stop code will handle things.
* Created a qemuDomainMasterKeyReadFile to handle reading the master.key
file during qemuProcessReconnect rather than the prior code which would
have taken the masterKey from the XML file in base64 format.
* The MasterKeyCreate and MasterKeyRemove incorporate the file manipulation
as well. The *Create code will save the base64 encoded secret. The callers
need only call those API's.
* The masterKey is generated using gnutls_rnd if that's available
(following examples w/ HAVE_GNUTLS_CRYPTO_H); otherwise, the fallback
position is the virRandomBits.
* Moved alias code to qemu_alias.c instead of qemu_domain.c.
Notes on comments where I didn't change things:
* Since qemuBuildCommandLine doesn't get the qemuDomainObjPrivate, I
kept the qemuBuildHasMasterKey checking the capability bit only.
Other *CommandLine callers would use the same decision point. If
the key was available, then "assume" it's already present on the
command line since there's no failure path from building the
master key command line.
* I kept the write "0" to the key file just before deletion. I wasn't
sure with file caches being as they can be if there could ever be that
100% guarantee that what was unlink()'d really "went away" completely.
Something I noted and wasn't "clear" how to resolve, so I followed existing
practices of not checking if something exists:
* The recent changes to have a qemuProcessCreatePretendCmd which will
allow libDir and channelTargetDir creation using "/tmp/", but not
actually creating the directory inhibit this code from being able to
check if the path to the masterKey exists before sending it to qemu.
Now if the 'flags' was passed to qemuBuildCommandLine and the
VIR_QEMU_PROCESS_START_PRETEND could be checked while building the
MasterKey command line, then I could have the check in. Otherwise,
I just have to assume everything's worked "right" up to this point.
A secondary note on that... Why "/tmp/" - shouldn't have been
"tmp/"?
John Ferlan (3):
qemu: Add capability bit for qemu secret object
qemu: Create domain master key
qemu: Introduce qemuBuildMasterKeyCommandLine
src/qemu/qemu_alias.c | 17 ++
src/qemu/qemu_alias.h | 3 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 68 ++++++
src/qemu/qemu_domain.c | 269 +++++++++++++++++++++
src/qemu/qemu_domain.h | 13 +
src/qemu/qemu_process.c | 11 +
tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 +
tests/qemucapabilitiesdata/caps_2.6.0-1.replies | 3 +
.../qemuxml2argvdata/qemuxml2argv-master-key.args | 23 ++
tests/qemuxml2argvdata/qemuxml2argv-master-key.xml | 30 +++
tests/qemuxml2argvtest.c | 2 +
13 files changed, 443 insertions(+)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-master-key.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-master-key.xml
--
2.5.0