[libvirt] [PATCH 1/3] storage: refresh volume before deletion

[Pavel Hrdina]

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