Description of problem: If a storage pool is located on a root-squashed NFS share, and that pool has existing storage volumes, when the pool is re-started it will fail. Version-Release number of selected component (if applicable): libvirt-0.7.7 and all previous releases How reproducible: 0) perform the following test on a setup that has user and group in /etc/libvirt/qemu.conf both set to "qemu". 1) create a pool on a root-squashed NFS server (with uid/gid/mode of qemu/qemu/0700) and start it (you won't be able to "build" it - just manually create the directory on the server ahead of time, then start the pool). 2) create at least one volume in the pool. Be sure that the volume's xml permissions are also "qemu/qemu/0700" 3) stop the pool (with virsh pool-destroy) 4) restart the pool (virsh pool-start) Actual results: virsh # pool-start netfs-pool error: Failed to start pool netfs-pool error: cannot open volume '/netfs-pool/netfs-qemu.img': Permission denied Expected results: virsh # pool-start netfs-pool Pool netfs-pool started Additional info:
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
More details: When a pool is started,the "refresh" callback is called. In the case of directory pools, this goes to virStorageBackendFileSystemRefresh(), which first opens the directory itself and reads each entry (this could fail if the directory is not readable by root), and then for each existing file in the directory, calls virStorageBackendProbeTarget(), which will open the file, fstat it, and lseek to the end, among other things - of course these also could fail if the storage volume file isn't readable by root (which it probably shouldn't be). Because the operations on the directories / files involve more than just reading from or writing to the file, the solution will be a bit involved.
*** Bug 612343 has been marked as a duplicate of this bug. ***
With the recent addition of virFileOpenAs(), the solution to this problem should be more straightforward.
*** Bug 612346 has been marked as a duplicate of this bug. ***
There's qemuOpenFile that could be used for this if you're using qemu connection, we just need to make that available in the storage driver, maybe similarly to xmlopt during domain parsing...
I see OpenAs calls in src/storage/storage_driver.c nowadays, but no idea if it affects this bug without digging deeper. Anyone with a root-squash NFS setup can confirm this is still valid?
(In reply to Cole Robinson from comment #12) > I see OpenAs calls in src/storage/storage_driver.c nowadays, but no idea if > it affects this bug without digging deeper. Anyone with a root-squash NFS > setup can confirm this is still valid? Setting NEEDINFO
No response, so closing. If anyone can still reproduce and is affected by these, please reopen