Bug 1364048
| Summary: | [API] Not possible to access /clusters collection in user level api in version 3 of the API | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Gonza <grafuls> |
| Component: | Backend.Core | Assignee: | Juan Hernández <juan.hernandez> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Lucie Leistnerova <lleistne> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 4.0.2 | CC: | bugs, dfediuck, gklein, grafuls, juan.hernandez, lleistne, mgoldboi, michal.skrivanek, ncredi, omachace, pstehlik, rgolan, sbonazzo |
| Target Milestone: | ovirt-4.0.2 | Keywords: | AutomationBlocker, Regression |
| Target Release: | 4.0.2.6 | Flags: | rule-engine:
ovirt-4.0.z+
rule-engine: blocker+ rule-engine: planning_ack+ rule-engine: devel_ack+ pstehlik: testing_ack+ |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-17 14:44:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | SLA | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Please share engine log, when quering this command: $ curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Prefer: persistent-auth" -H "Filter: True" -H "Cookie: JSESSIONID=qOfLbt6g26QtRdJvrZFWoE3bycH8Gs5vQjpvV-4t.xxx; path=/ovirt-engine/api; secure; HttpOnly" -H "Session-TTL: 3600" -H "Version: 3" -L https://xxx.redhat.com:443/ovirt-engine/api/clusters <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <reason>Operation Failed</reason> <detail>query execution failed due to insufficient permissions.</detail> </fault> 2016-08-04 13:53:08,111 DEBUG [org.ovirt.engine.core.bll.Backend] (default task-1) [] Executing query GetAllClusters with isFiltered : true for user admin@internal-authz. 2016-08-04 13:53:08,145 DEBUG [org.ovirt.engine.core.bll.Backend] (default task-1) [] Executing query GetClusterPolicyById with isFiltered : true for user admin@internal-authz. 2016-08-04 13:53:08,148 ERROR [org.ovirt.engine.core.bll.scheduling.queries.GetClusterPolicyByIdQuery] (default task-1) [] Query execution failed due to insufficient permissions. 2016-08-04 13:53:08,150 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: query execution failed due to insufficient permissions. Issue is in GetClusterPolicyByIdQuery - most probably it should be user query. (In reply to Ondra Machacek from comment #2) > 2016-08-04 13:53:08,111 DEBUG [org.ovirt.engine.core.bll.Backend] (default > task-1) [] Executing query GetAllClusters with isFiltered : true for user > admin@internal-authz. > 2016-08-04 13:53:08,145 DEBUG [org.ovirt.engine.core.bll.Backend] (default > task-1) [] Executing query GetClusterPolicyById with isFiltered : true for > user admin@internal-authz. > 2016-08-04 13:53:08,148 ERROR > [org.ovirt.engine.core.bll.scheduling.queries.GetClusterPolicyByIdQuery] > (default task-1) [] Query execution failed due to insufficient permissions. > 2016-08-04 13:53:08,150 ERROR > [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default > task-1) [] Operation Failed: query execution failed due to insufficient > permissions. > > Issue is in GetClusterPolicyByIdQuery - most probably it should be user > query. no, why should a uservmmanager see policyunit? Can you test that against 3.6? when exactly did it cause a regression in 4.0? Waht's the last working build? Comparing to the UI, a user using user portal or power user portal will not have access to the cluster scheduling information (especially the system configuration). Hence this is working by design. If you require access to the scheduling information you should be using an admin user. Please close this issue. (In reply to Doron Fediuck from comment #5) > Comparing to the UI, a user using user portal or power user portal will not > have access to the cluster scheduling information (especially the system > configuration). > > Hence this is working by design. If you require access to the scheduling > information you should be using an admin user. Please close this issue. There is clearly a mismatch of behavior between v3 and v4. I believe this still needs to be addressed. when exactly did it cause a regression in 4.0? What's the last working build? Why 3.6.7 SDK is used here? Shouldn't it be 3.6.8? And why rhevm-4.0.2-0.2.rc1.el7ev.noarch ? Latest build was 4.0.2.4. afaik it also failed on rhevm-4.0.2.4-0.1.el7ev.noarch no idea why other sdks are mentioned, but it is failing in rest api (In reply to Gonza from comment #6) > (In reply to Doron Fediuck from comment #5) > > Comparing to the UI, a user using user portal or power user portal will not > > have access to the cluster scheduling information (especially the system > > configuration). > > > > Hence this is working by design. If you require access to the scheduling > > information you should be using an admin user. Please close this issue. > > There is clearly a mismatch of behavior between v3 and v4. I believe this > still needs to be addressed. Fine, but is this an automation blocker? Can't you use there admin user? I created new user, added him to engine, he gets default roles (Everyone)
api call on /clusters without "Filter: true" for this new user returns error
<fault>
<detail>query execution failed due to insufficient permissions.</detail>
<reason>Operation Failed</reason>
</fault>
api call on /clusters with "Filter: true" returns cluster Default
<clusters>
<cluster href="/ovirt-engine/api/clusters/00000002-0002-0002-0002-0000000001aa" id="00000002-0002-0002-0002-0000000001aa">
<actions>
<link href="/ovirt-engine/api/clusters/00000002-0002-0002-0002-0000000001aa/resetemulatedmachine" rel="resetemulatedmachine"/>
</actions>
<name>Default</name>
...
There is not this new user in Permissions on the Default cluster, I see only admin.
Then I added for the user UserVmManager role on other cluster, api call on /clusters with "Filter: true" returns both Default and this cluster
Why does the user see Default cluster without permissions on it? Is this the right behavior?
tested in ovirt-engine-restapi-4.0.2.6-0.1.el7ev.noarch
If I understand correctly a user can see a cluster if he can see any VM or template of that cluster. All users can see the Blank template. The Blank template is in all clusters. Therefore all users can see all clusters. If that is an issue please open a new bug. In my opinion this bug should be verified if the user with the "UserVmManager" role can see the cluster. Yes, the user had permissions to Blank template, after removing it, he can't see Default cluster and sees only the other one. verified in ovirt-engine-restapi-4.0.2.6-0.1.el7ev.noarch |
Description of problem: User with UserVmManager role on VM is not able to GET clusters via v3 API using Filter header. Version-Release number of selected component (if applicable): rhevm-4.0.2-0.2.rc1.el7ev.noarch python-ovirt-engine-sdk4-4.0.0-0.0.a3.el7ev.x86_64 ovirt-engine-sdk-python-3.6.7.0-1.el7ev.noarch ovirt-engine-sdk-java-3.6.7.0-1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. $ curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Prefer: persistent-auth" -H "Filter: True" -H "Cookie: JSESSIONID={SESSION_ID}; path=/ovirt-engine/api; secure; HttpOnly" -H "Session-TTL: 3600" -H "Version: 3" -L https://{engine}.com:443/ovirt-engine/api/clusters Actual results: (Pdb) self.api.headers {'Version': '3', 'Prefer': 'persistent-auth', 'Session-TTL': 3600, 'Filter': 'True'} (Pdb) print self.get(href, listOnly=True) None (Pdb) self.api.headers['Version']='4' (Pdb) self.get(href, listOnly=True) [<art.rhevm_api.data_struct.data_structures.Cluster object at 0x7fd726730290>, <art.rhevm_api.data_struct.data_structures.Cluster object at 0x7fd726730210>, <art.rhevm_api.data_struct.data_structures.Cluster object at 0x7fd71ed14590>] ======================================================================== $ curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Prefer: persistent-auth" -H "Filter: True" -H "Cookie: JSESSIONID=qOfLbt6g26QtRdJvrZFWoE3bycH8Gs5vQjpvV-4t.xxx; path=/ovirt-engine/api; secure; HttpOnly" -H "Session-TTL: 3600" -H "Version: 3" -L https://xxx.redhat.com:443/ovirt-engine/api/clusters <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <reason>Operation Failed</reason> <detail>query execution failed due to insufficient permissions.</detail> </fault> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- $ curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Prefer: persistent-auth" -H "Filter: True" -H "Cookie: JSESSIONID=qOfLbt6g26QtRdJvrZFWoE3bycH8Gs5vQjpvV-4t.xxx; path=/ovirt-engine/api; secure; HttpOnly" -H "Session-TTL: 3600" -H "Version: 4" -L https://xxx.redhat.com:443/ovirt-engine/api/clusters <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <clusters> <cluster href="/ovirt-engine/api/clusters/00000002-0002-0002-0002-00000000027c" id="00000002-0002-0002-0002-00000000027c"> <actions> ...