The following series of patches resolve a few issues found within
and because of an NFS root-squash environment.
Patch 1: No real change - mostly to get data on which path was failing
Patch 2: Create a virFileUnlink() API which will essentially follow the
code that virFileCreateAs[Forked] and virDirCreate[NoFork] have taken
with respect to running the 'unlink' in a fork'd process under the uid/gid
used to create the volume.
Patch 3: Commit id '7c2d65dde2' used the default mode to create a file
when "vol->target.perms->mode" was set rather than checking it against
-1 in virStorageBackendCreateRaw when calling virFileOpenAs. The logic
was change to follow other changes which check "->mode == -1", then use
default, else use "->mode" value.
Patch 4: Commit id '155ca616' added a check and call to a storage driver
'refreshVol' API. Unfortunately if it failed, proper cleanup wasn't done
leaving 'voldef' set and already in the pool list. The cleanup path would
then delete the memory eventually leading to a crash or corruption for an
ensuing refresh or list pool. For an NFS root squash environment with
incorrect XML to create the file (either wrong uid/gid or mode value),
the refreshVol would fail since it tried to run as root. On such a failure,
it was possible that the volume remained in the NFS pool when it should
have been deleted (unless root could delete the file).
The last 3 patches are very much so related and intertwined. Fortunately
it's a very limited environment.
John Ferlan (4):
virfile: Add error for root squash change mode failure
virfile: Introduce virFileUnlink
storage: Correct the 'mode' check
storage: Handle failure from refreshVol
src/libvirt_private.syms | 1 +
src/storage/storage_backend.c | 8 +--
src/storage/storage_backend_fs.c | 3 +-
src/storage/storage_driver.c | 6 ++-
src/util/virfile.c | 113 ++++++++++++++++++++++++++++++++++++++-
src/util/virfile.h | 1 +
6 files changed, 126 insertions(+), 6 deletions(-)
--
2.1.0