Bug 924357 - [RHEVM-SDK] user should not see admin permissions the DC
Summary: [RHEVM-SDK] user should not see admin permissions the DC
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-sdk
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.2.0
Assignee: Michael Pasternak
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-21 15:39 UTC by Ondra Machacek
Modified: 2016-02-10 19:40 UTC (History)
10 users (show)

Fixed In Version: sf13-beta2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 13562 0 None None None Never
oVirt gerrit 13563 0 None None None Never

Description Ondra Machacek 2013-03-21 15:39:05 UTC
Description of problem:
It is not possible to work properly in multi instance mode in SDK.

Version-Release number of selected component (if applicable):
sf10

How reproducible:
rhevm-sdk-3.2.0.5-1.el6ev.noarch

Steps to Reproduce:
1. Add user with UserRole on some vm.
2. Run code below.

import ovirtsdk.api
API_user = ovirtsdk.api.API(url=url, username=user, password=pwd, filter=True)
API_admin = ovirtsdk.api.API(url=url, username=adm, password=pwd, filter=False)

print len(API_user.datacenters.list()[0].permissions.list())
print len(API_admin.datacenters.list()[0].permissions.list())

Result:
0
Traceback (most recent call last):
  File "./t.py", line 12, in <module>
    print API_admin.datacenters.list()[0].permissions.list()
  File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/brokers.py", line 1449, in list
    {'{datacenter:id}': self.parentclass.get_id()}
  File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/proxy.py", line 140, in get
    return self.request(method='GET', url=url, headers=headers)
  File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/proxy.py", line 199, in request
    noParse=noParse)
  File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/proxy.py", line 244, in __doRequest
    raise RequestError, response
ovirtsdk.infrastructure.errors.RequestError: 
status: 400
reason: Bad Request
detail: query execution failed due to insufficient permissions.
----------------------------------------------------------------
If I switch 'prints':
print len(API_admin.datacenters.list()[0].permissions.list())
print len(API_user.datacenters.list()[0].permissions.list())

Result is:
3
2

OK in rhevm-sdk-3.2.0.2-1.el6ev.noarch.

Comment 2 Michael Pasternak 2013-03-24 12:16:54 UTC
Ondra,

can you please elaborate what do you mean by "Multi-instance user mode don't
work as expected"?

- multi-instance feature of sdk is related to creating several instances
of the sdk under same memory domain

- in your example seems like adm user fails to execute the query due
to "insufficient permissions"

i'm not sure i understand how these two are related.

Comment 3 Ondra Machacek 2013-03-25 11:36:11 UTC
Let's say I have user with UserRole on vm and admin@internal.

I create instance of API like this:
API_user = ovirtsdk.api.API(url=url, username=user, password=pwd, filter=True)
API_admin = ovirtsdk.api.API(url=url, username=adm, password=pwd, filter=False)

I have no permissions on 'mydc' only admin@internal have inherited permissions from system. Now if I run these line of code:

print len(API_admin.datacenters.get('mydc').permissions.list())
print len(API_user.datacenters.get('mydc').permissions.list())

As a result I got:
1
1

Which is incorrect, because user should not see admin permissions on 'mydc'.
This happens only via SDK, if I run this not via SDK, but via API directly result is OK:

for admin:
curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml"  -H "Filter: $filter" -u $U $URL/datacenters/$dc_id/permissions 

<permissions>
    <permission .../>
</permissions>

for user:
curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml"  -H "Filter: $filter" -u $U $URL/datacenters/$dc_id/permissions

<permissions/>


In comment #0 I showed that reverse order only for example, because i think that admin@internal should never get "insufficient permissions", so it seems as some problem with filter=true/false. As I noted in rhevm-sdk-3.2.0.2-1.el6ev.noarch I did not meet with this issue.

Comment 4 Michael Pasternak 2013-03-27 11:58:02 UTC
(In reply to comment #3)
> Let's say I have user with UserRole on vm and admin@internal.
> 
> I create instance of API like this:
> API_user = ovirtsdk.api.API(url=url, username=user, password=pwd,
> filter=True)
> API_admin = ovirtsdk.api.API(url=url, username=adm, password=pwd,
> filter=False)
> 
> I have no permissions on 'mydc' only admin@internal have inherited
> permissions from system. Now if I run these line of code:
> 
> print len(API_admin.datacenters.get('mydc').permissions.list())
> print len(API_user.datacenters.get('mydc').permissions.list())
> 
> As a result I got:
> 1
> 1
> 
> Which is incorrect, because user should not see admin permissions on 'mydc'.
> This happens only via SDK, if I run this not via SDK, but via API directly
> result is OK:
> 
> for admin:
> curl -k -X GET -H "Accept: application/xml" -H "Content-Type:
> application/xml"  -H "Filter: $filter" -u $U
> $URL/datacenters/$dc_id/permissions 
> 
> <permissions>
>     <permission .../>
> </permissions>
> 
> for user:
> curl -k -X GET -H "Accept: application/xml" -H "Content-Type:
> application/xml"  -H "Filter: $filter" -u $U
> $URL/datacenters/$dc_id/permissions
> 
> <permissions/>

i suspect that you misused $filter here (i.e it is the same in both curl calls),
in any case sdk doesn't have own logic and pass params as they are, i.e it
should behave exactly as api.

Comment 10 Michael Pasternak 2013-04-03 14:32:24 UTC
well done Ondra!

Comment 13 Itamar Heim 2013-06-11 08:26:37 UTC
3.2 has been released

Comment 14 Itamar Heim 2013-06-11 08:26:42 UTC
3.2 has been released


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