On 03/10/2016 04:30 AM, Ján Tomko wrote: > 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 >> > > For local filesystems, root should be able to remove anything. > For root-squashed NFS, the uid:gid will usually be nobody:nobody > the whole time, so this refresh is unlikely to learn something new. > > I think the real fix is patch 3/3 that stops doing setuid on NFS. Hmm yeah I was forgetting some NFS details :) Thanks for correcting me. I'll drop this patch - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list