On Wed, Jun 01, 2016 at 11:11:40AM -0400, John Ferlan wrote: > > > 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? Yep, using a master secret does not really buy us any benefit when using qemu-img in one-shot mode. The main rational for the master secret feature was to facilitate QEMU hotplug, so that you could securely pass secrets to a running QEMU without having to create files on disk for every single secret you pass over the QMP monitor. With qemu-img being a short-lived process doing individual specific tasks, it is fine to just save the real secret on disk in either raw or base64 format, and directly reference it without using a master secret. In terms of permissions it is sufficient to make sure the file is simply -r------- & owned by the uid/gid that we're invoking qemu-img under. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list