On Mon, Dec 09, 2019 at 07:50:09 +0100, Christian Ehrhardt wrote: > On Fri, Oct 11, 2019 at 9:13 PM Cole Robinson <crobinso@xxxxxxxxxx> wrote: > > > > Teach virt-aa-helper how to label a qcow2 data_file, tracked internally > > as externalDataStore. It should be treated the same as its sibling > > disk image > > > > Signed-off-by: Cole Robinson <crobinso@xxxxxxxxxx> > > --- > > Compiled but not runtime tested, I don't have an apparmor setup > > > > src/security/virt-aa-helper.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c > > index 509187ac36..fe6fa12550 100644 > > --- a/src/security/virt-aa-helper.c > > +++ b/src/security/virt-aa-helper.c > > @@ -949,6 +949,10 @@ storage_source_add_files(virStorageSourcePtr src, > > if (add_file_path(tmp, depth, buf) < 0) > > return -1; > > > > + if (src->externalDataStore && > > + storage_source_add_files(src->externalDataStore, buf, depth) > < 0) > > + return -1; > > + > > After thinking twice about it ack to carry over depth as only the first > layer should only ever need write permissions on those extra files as well. > > But I'm unsure about using "src->externalDataStore". > After all this does initialize "tmp = src". > And then iterates the (potential) backing chain. > That way each loop iteration has a different "tmp" along the backing chain > but "src" will always point to the first entry. > > It comes down to a detail question about the design of external data in > qcow. > In a case with a base file and two snapshots, does the chain look like: > > A: > Current -> Snap2 -> Snap1 > \ > external data > > or > B: > > Current -> Snap2 -> Snap1 > \ \ \ > ext-dat2 ext-dat1 ext-dat This is the correct situation as the store is an per-image property. Any level in the backing chain may or may not have it depending on how you create the image. The external data store write permission must mirror the permission of the image it belongs to, so that if you are e.g. committing one of the snapshots the backing store must be turned writable as qemu will write the data into it. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
