Commit 35847860 introduced virFileUnlink() to fix an issue with deleting
volumes on NFS root-squashed environment. This patch replace the uid
and gid magic by virFileIsSharedFSType() to correctly detect that the
volume is on NFS storage.
This fixes the referenced bug. To reproduce this bug follow those
steps on a domain with local storage:
virsh start $domain
virsh pool-refresh $pool
virsh destroy $domain
virsh vol-delete $volume $pool
The thing is, that the pool-refresh will store qemu:qemu as uid:gid for
that volume and after destroy the volume is relabeled back to root:root.
Then you run vol-delete and the virFileRemove() function will try to
unlink the file as a qemu:qemu process based on the uid and gid magic.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1260356
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
src/util/virfile.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/util/virfile.c b/src/util/virfile.c
index f45e18f..f9c5bb1 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -2334,13 +2334,16 @@ virFileRemove(const char *path,
int status = 0, ret = 0;
gid_t *groups;
int ngroups;
+ int rc;
/* If not running as root or if a non explicit uid/gid was being used for
* the file/volume or the explicit uid/gid matches, then use unlink directly
*/
- if ((geteuid() != 0) ||
- ((uid == (uid_t) -1) && (gid == (gid_t) -1)) ||
- (uid == geteuid() && gid == getegid())) {
+ rc = virFileIsSharedFSType(path, VIR_FILE_SHFS_NFS);
+ if (rc < 0)
+ return -EINVAL;
+
+ if (rc == 0) {
if (virFileIsDir(path))
return rmdir(path);
else
--
2.7.1