Bug 1364048 - [API] Not possible to access /clusters collection in user level api in version 3 of the API
Summary: [API] Not possible to access /clusters collection in user level api in versio...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.0.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ovirt-4.0.2
: 4.0.2.6
Assignee: Juan Hernández
QA Contact: Lucie Leistnerova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-04 11:36 UTC by Gonza
Modified: 2016-08-17 14:44 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-08-17 14:44:26 UTC
oVirt Team: SLA
Embargoed:
rule-engine: ovirt-4.0.z+
rule-engine: blocker+
rule-engine: planning_ack+
rule-engine: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 62172 0 master MERGED restapi: Ignore failures fetching cluster policy 2016-08-09 20:50:52 UTC
oVirt gerrit 62173 0 ovirt-engine-4.0 MERGED restapi: Ignore failures fetching cluster policy 2016-08-10 08:05:57 UTC
oVirt gerrit 62179 0 ovirt-engine-4.0.2 MERGED restapi: Ignore failures fetching cluster policy 2016-08-10 08:36:48 UTC

Description Gonza 2016-08-04 11:36:25 UTC
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>
...

Comment 1 Ondra Machacek 2016-08-04 11:44:40 UTC
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>

Comment 2 Ondra Machacek 2016-08-04 11:55:38 UTC
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.

Comment 3 Roy Golan 2016-08-08 12:20:47 UTC
(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?

Comment 4 Michal Skrivanek 2016-08-08 12:39:22 UTC
when exactly did it cause a regression in 4.0? Waht's the last working build?

Comment 5 Doron Fediuck 2016-08-08 12:47:29 UTC
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.

Comment 6 Gonza 2016-08-08 12:56:16 UTC
(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.

Comment 7 Michal Skrivanek 2016-08-09 08:21:33 UTC
when exactly did it cause a regression in 4.0? What's the last working build?

Comment 8 Sandro Bonazzola 2016-08-09 09:18:26 UTC
Why 3.6.7 SDK is used here? Shouldn't it be 3.6.8?

Comment 9 Sandro Bonazzola 2016-08-09 09:19:36 UTC
And why rhevm-4.0.2-0.2.rc1.el7ev.noarch ?
Latest build was 4.0.2.4.

Comment 10 Nelly Credi 2016-08-09 09:46:36 UTC
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

Comment 11 Yedidyah Bar David 2016-08-09 09:48:53 UTC
(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?

Comment 12 Lucie Leistnerova 2016-08-15 12:10:18 UTC
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

Comment 13 Juan Hernández 2016-08-16 09:13:53 UTC
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.

Comment 14 Lucie Leistnerova 2016-08-16 10:55:20 UTC
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


Note You need to log in before you can comment on or make changes to this bug.