Re: [libvirt] [PATCH 2/4] qemu: Introduce qemuBuildSecretObjectProps

On 06/01/2016 09:10 AM, Daniel P. Berrange wrote: > On Wed, Jun 01, 2016 at 09:04:00AM -0400, John Ferlan wrote: >> My quandary is less about the qemu-img infrastructure than the storage >> driver code. >> >> That is, it's "less clear" in my mind how the storage_backend.c code >> would need to handle a ",file=" for its short lived master key. Where to >> create the file? What issues around permissions will there be? >> Basically anything that virSecurityManagerDomainSetPathLabel handles for >> the domain master key. I've been working under the assumption that it'll >> need to be done, but hadn't quite got that far yet. > > I see three possible options > > 1 Have storage driver create a random master key when libvirtd starts up > and use that with all qemu-img invokations > > 2 Have storage driver create a random master key per pool and use that > with all qemu-img invokations against that pool > I wasn't thinking that this key would need to be stored long term, although I suppose that works too using the driver->stateDir as the location and building the file name using master-key.aes. I had been leaning towards generating it on the fly as needed. It was more the mgmt of the file for what amounts to one operation. Of course while typing and thinking generating a temporary file on the fly has drawbacks too. > 3 Ignore master keys entirely and just put the encryption key for the > luks volume in a file directly. ie just one secret object using file= > instead of two secret objects > Just to be clear - the key could be base64 encoded raw text in a file? Or just the raw text in a file. Too bad we couldn't link to the secret driver file directly... In either case it's still not clear what protections are sufficient. That is would there need to be a virSecurityManagerDomainSetPathLabel type call in order for qemu-img to use the file or would creating the file in driver->stateDir be sufficient?