Description of problem: you must allow read access for "other" in order to use an iso on an iso domain The Documentation is somewhat unclear: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Administration_Guide/sect-Preparing_and_Adding_File-based_Storage.html It states: "The permissions on the directory must be set to allow read and write access to both the owner and the group. The owner should also have execute access to the directory." This implies that no read access for "other" is needed, however the documentation also uses this command: "chmod 0755 /exports/iso" which is contradicting the above statement. Version-Release number of selected component (if applicable): 3.3.3 How reproducible: always Steps to Reproduce: 1. copy an ISO image via scp on the nfs server on EL6, the default umask makes it not readable by "other" 2. watch webadmin, click refresh on the iso domain, the iso doesn't appear 3. change permission to allow "read" for "others", click refresh again, the iso appears Actual results: isos are just shown in webadmin when they are readable by "others" Expected results: isos are shown in webadmin when they are readable by just "group" and "user" Additional info:
Yoav, can you please have a look? It might be related to root squash
Bug was reported against 3.3, not reason to block 3.5.0 on it - pushing out to 3.5.1
As of today (3.6 master) the expected behavior works for me. In fact, it's a little more lenient. Closing, please reopen if you see it again. Details: On my NFS share (no squashing), I can see any ISOs with group 'qemu' or 'kvm' having read permissions for the user and group having the group 'qemu' or 'kvm'. With all_squash, any owner will do as long as the image is 440 or better. This is corroborated in the code, where it verifies that the iso is readable by others, OR that the group is correct and can read the iso.
(In reply to Greg Padgett from comment #3) > This is corroborated in the code, where it verifies that the iso is readable > by others, OR that the group is correct and can read the iso. Can we find which patch introduced this behavior please? I'd like to understand if we fixed this (without noticing the BZ report), or whether there's some misunderstanding here.
My statement regarding the documentation is still true and should be fixed. Or don't you fix documentation bugs for this old release anymore? This was "fixed" somehow in 3.5 docs here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Preparing_and_Adding_NFS_Storage.html however it tells you to use user:group 36 in which case you should not need 0755 rights on this file. one might even argue that this is not as secure, because it opens the possibility that unintended unix users can read iso images which they should not be able to see.
(In reply to Allon Mureinik from comment #4) > (In reply to Greg Padgett from comment #3) > > This is corroborated in the code, where it verifies that the iso is readable > > by others, OR that the group is correct and can read the iso. > Can we find which patch introduced this behavior please? > I'd like to understand if we fixed this (without noticing the BZ report), or > whether there's some misunderstanding here. Interesting, nothing has changed here since around 3.3 time except a little code to add Ubuntu support, which consisted only of defining the group names for that OS in the makefile (actually configure.ac). Maybe I'm missing something. Sven, do you remember details of the nfs export owner/group, iso owner/group, and any special nfs export configuration you may have used? (Alternatively, is it still reproducible?) I also looked more closely at the documentation now that you mentioned the discrepancy again. I can see it says to chmod the export directory to 0755 when creating the share. (I tried with 0750 also, which works, but when adding the domain the metadata is all written in the share with 0755 permissions anyway.) On the other hand, I can't find instructions in the documentation about manually copying the ISOs--only to use the ISO uploader[1,2], which will chmod the ISOs to 0640. [1] 3.3: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Administration_Guide/Populating_the_ISO_Storage_Domain1.html [2] 3.5: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Storage_Tasks.html#Populating_the_ISO_Storage_Domain1
(In reply to Sven Kieske from comment #5) > My statement regarding the documentation is still true and should be fixed. > > Or don't you fix documentation bugs for this old release anymore? > > This was "fixed" somehow in 3.5 docs here: > > https://access.redhat.com/documentation/en-US/ > Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect- > Preparing_and_Adding_NFS_Storage.html > > however it tells you to use user:group 36 in which case you should not need > 0755 rights on this file. > > one might even argue that this is not as secure, because it opens the > possibility > that unintended unix users can read iso images which they should not be able > to see. I agree. Andrew - how should we handle this?
Note also that local storage documentation has the same 0750 (text) vs 0755 (example code) discrepancy.
Hi Allon, Thank you for the needinfo request. In earlier releases of RHEV, I seem to recall that the permissions had to be set to exactly 0755 for the ISO files to be recognized by RHEV, but this doesn't seem to be as strict in more recent releases. Is there a specific combination of permissions and ownership that we should specify? I certainly understand the concern about security, so as long as we know what we should recommend, we can update the documentation to reflect that. Kind regards, Andrew
(In reply to Andrew Dahms from comment #9) > Is there a specific combination of permissions and ownership that we should > specify? Greg, can you sum up your conclusions please?
(In reply to Allon Mureinik from comment #10) > (In reply to Andrew Dahms from comment #9) > > Is there a specific combination of permissions and ownership that we should > > specify? > Greg, can you sum up your conclusions please? I looked into it a little further. For ISO domains, if the directory is owned by vdsm:kvm with permissions 0750, I can see the ISO list in webadmin but cannot see a mounted ISO from within a running VM [1]. When all components of the path are 0755, the ISO is usable. I think it requires further investigation, as there appears to be some permission missing that's required under certain scenarios. In the meantime I'll put this bug back in assigned state and leave needinfo? on me. [1] from the system journal: libvirtd[1324]: can't canonicalize path '/rhev/data-center/mnt/ovirt.localdomain:_storage_iso1/09bb7379-e5b3-4400-9aa5-f43924c543fd/images/11111111-1111-1111-1111-111111111111/Fedora-22-x86_64-Live-Workstation-3.iso': Permission denied
(In reply to Greg Padgett from comment #11) > but cannot see a mounted ISO from within a running VM [1]. When all (editing error... I meant that no ISOs are usable from within a VM.)
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still an issue.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
(In reply to Greg Padgett from comment #11) > (In reply to Allon Mureinik from comment #10) > > (In reply to Andrew Dahms from comment #9) > > > Is there a specific combination of permissions and ownership that we should > > > specify? > > Greg, can you sum up your conclusions please? > > I looked into it a little further. For ISO domains, if the directory is > owned by vdsm:kvm with permissions 0750, I can see the ISO list in webadmin > but cannot see a mounted ISO from within a running VM [1]. When all > components of the path are 0755, the ISO is usable. > > I think it requires further investigation, as there appears to be some > permission missing that's required under certain scenarios. In the meantime > I'll put this bug back in assigned state and leave needinfo? on me. > > > [1] from the system journal: > libvirtd[1324]: can't canonicalize path > '/rhev/data-center/mnt/ovirt.localdomain:_storage_iso1/09bb7379-e5b3-4400- > 9aa5-f43924c543fd/images/11111111-1111-1111-1111-111111111111/Fedora-22- > x86_64-Live-Workstation-3.iso': Permission denied The required permissions--and reason for the requirements--to allow successful iso/domain operations are listed below: iso file: vdsm:kvm 0640 - vdsm must access the file to provide the iso list to engine. 0440 might work, but a) iso-uploader chmod's to 0640, and b) if/when iso management becomes more integrated, vdsm having write permission on the isos will be useful. - qemu requires read access to serve the image to the vm (access is via kvm group) nfs share directory: vdsm:kvm 0755 - libvirtd runs as root and calls canonicalize_file_name() on the iso file, which requires read access to the directory (access via others) It might be nice if libvirtd could setgid(kvm) for the canonicalize_file_name() call so that the iso share could be vdsm:kvm 0750, though it's possible further downstream operations would require the same change. As it stands now, the above are required. Andrew, does this cover everything needed for the documentation?
Greg, is something needed here aside for a change in the documentation?
(In reply to Tal Nisan from comment #17) > Greg, is something needed here aside for a change in the documentation? Just documentation AFAIK. Not sure we care about asking for libvirt changes that would allow iso directory to be 0750... but that wouldn't happen immediately anyway.
(In reply to Greg Padgett from comment #18) > (In reply to Tal Nisan from comment #17) > > Greg, is something needed here aside for a change in the documentation? > > Just documentation AFAIK. Not sure we care about asking for libvirt changes > that would allow iso directory to be 0750... but that wouldn't happen > immediately anyway. Closing, based on this comment. Andrew - how do you want to track the documentation requirement?
Hi Allon, Thank you for the needinfo request. We will create a separate docs bug to track the effort, and will look into it for you there. We will reach out again later with the bug ID. Kind regards, Andrew
Reopening (this is really sad): Today I'm trying to setup ovirt 3.6.6 (from snapshot 3.6 repo). So I got an ISO Domain setup (empty of course) and I want to upload an image from my ovirt-engine with this command: engine-iso-uploader -u admin@internal -i myisodomain upload myiso.iso Then I look into webadmin, if my iso will appear in the ISO Domain, but no, it won't. So I look at the permissions on the nfs server where engine-iso-uploader uploads the iso: l /home/iso1/9ba22bfe-d760-48c9-b4a5-10149cb4ecb9/images/11111111-1111-1111-1111-111111111111/myiso.iso -rw-r-----. 1 36 36 379492352 2016-04-29 09:22 /home/iso1/9ba22bfe-d760-48c9-b4a5-10149cb4ecb9/images/11111111-1111-1111-1111-111111111111/myiso.iso When you chmod o+r the file it will appear in webadmin as visible immediately. So if you refuse to fix this in libvirt, or wherever, please at least fix then engine-iso-uploader to upload the file with the correct permissions. affected version: ovirt-image-uploader-3.6.1-0.0.master.20151006154111.git95ce637.el7.centos.noarch for completeness sake, here are the minimum required rights needed to see isos on the domain: l /home/iso1/9ba22bfe-d760-48c9-b4a5-10149cb4ecb9/images/11111111-1111-1111-1111-111111111111/myiso.iso -rw-r--r--. 1 36 36 379492352 2016-04-29 09:22 /home/iso1/9ba22bfe-d760-48c9-b4a5-10149cb4ecb9/images/11111111-1111-1111-1111-111111111111/myiso.iso
Greg, can you re-check what the status is, based on comment 21 ?
(In reply to Yaniv Kaul from comment #23) > Greg, can you re-check what the status is, based on comment 21 ? I'll take a look. Sven, can you share your NFS share settings (all_squash, etc) to help me reproduce it? Thanks.
(In reply to Greg Padgett from comment #24) > (In reply to Yaniv Kaul from comment #23) > > Greg, can you re-check what the status is, based on comment 21 ? > > I'll take a look. > > Sven, can you share your NFS share settings (all_squash, etc) to help me > reproduce it? Thanks. Sure, options on the nfs server in /etc/exports (running EL6) are: rw,sync,no_subtree_check but it really doesn't matter, adding all_squash does not fix the problem. I tested via NFSv4 btw. HTH :-)
oVirt 4.0 beta has been released, moving to RC milestone.
BTW, I believe setting the directory permissions to 0751 should be enough.
I just don't see this happening for 4.0, unfortunately.
Will move back to "Assigned" again when 4.0.z bugs will be off the table
Can you please reply on comment #27?
(In reply to Jiri Denemark from comment #27) > BTW, I believe setting the directory permissions to 0751 should be enough. Sorry for the late reply, I was on vacation. I can not confirm, nor disprove this, as I really have no time atm to test this. But I also do not understand how this is relevant to the proposed fix? kind regards Sven
ISO uploader is now deprecated, 4.2 introduced the ability to use ISOs on data domains and upload them through the REST/UI
WIP - updating the doc text
Preliminary text for the Doc Text field.