On Wed, Mar 09, 2016 at 12:38:58PM -0500, Cole Robinson wrote: > file volume deletion, via virFileRemove, has some logic that depends > on uid/gid owner of the path. This info is cached in the volume XML. > We need to be sure we are using up to date uid/gid before attempting > to delete the volume, otherwise we can hit a case like this: > > - test.img created with uid=root > - VM starts up using test.img, owner changed to uid=qemu > - test.img pool is refreshed, uid=qemu is cached in the volume XML > - VM shuts down, volume owner changed to gid=root > - vol-delete test.img thinks uid=qemu, virFileRemove does setuid(qemu), > fails to delete test.img since it is actually uid=root > > https://bugzilla.redhat.com/show_bug.cgi?id=1289327 > --- > src/storage/storage_driver.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) The storage volume refresh is a little bit tricky. We call it for some APIs but not for all of them. The root cause of this bug is that the uid/gid stored internally in libvirt and what's actually set for that storage could be inconsistent. To fix this for all that reports we would need to update the internal uid/gid while security driver modifies those uid/gid. The refreshVol shouldn't be needed unless someone makes modification without libvirt and needs to update internal state. In general, if we change something, we should now about that. Pavel -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list