[libvirt] [PATCH 0/3] Add a domain masterKey secret for qemu

[John Ferlan]

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