Bug 839319 - Permissions given to DataCenter level do not apply
Summary: Permissions given to DataCenter level do not apply
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Oved Ourfali
QA Contact: Tomas Dosek
URL:
Whiteboard: infra, ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-11 14:58 UTC by David Jaša
Modified: 2015-09-22 13:09 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-12 10:44:55 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description David Jaša 2012-07-11 14:58:02 UTC
Description of problem:
When user is granted any role on DC level, some of the permissions don't apply. This makes PowerUser and higer permissions granted on DataCenter-Permissions useless.

Version-Release number of selected component (if applicable):
si9.1

How reproducible:
always

Steps to Reproduce:
A.
1. add PowerUserRole to some user in DataCenter-Permissions tab
2. log in to User Portal

B.
1. as said PowerUser, create VM
2. create a disk for the VM

C.
1. in DataCenter-Permissions, add SuperUser role to some user
2. log in to webadmin ad the user in step above
3. try to create/import/modify storage domain

Actual results:
A. user can not access Power User Portal
B. dialog says that no active storage domain is available
C. none of the action is done, error is popped that user is not permitted to do the specified action

Expected results:
A. user can see Extended portal
B. user can create a disk
C. user can work with storage

Additional info:
note that it is possible to log to webadmin in C.

Comment 1 Simon Grinberg 2012-07-11 15:18:16 UTC
(In reply to comment #0)
I don't understand how you got to the result of B if A failed
C. Are you sure of this?

Both cases B and C indicate that your storage domain may have been down during your test - but again I don't understand how you got to B if in A you could not log into the portal in the first place.

Comment 2 David Jaša 2012-07-12 08:53:08 UTC
(In reply to comment #1)
> I don't understand how you got to the result of B if A failed

a clarification: A hits if you add permissions to group whose member is our user. Once you add the permissions to the user, he is able to see the portal and create a VM - but not to create the disk for it.

Comment 3 Yair Zaslavsky 2012-07-14 18:53:47 UTC
Sounds similar to
https://bugzilla.redhat.com/839490

But need to investigate this more .

Comment 7 RHEL Program Management 2012-07-29 12:46:41 UTC
Quality Engineering Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 8 David Jaša 2012-08-10 11:01:50 UTC
Still present in si13.2, marking as a regression because my 3.0 configuration is unusable in 3.1.

Comment 10 Yair Zaslavsky 2012-08-11 16:20:44 UTC
Checking upstream env (including some changes inserted after SI13.2 was released) -
Scenario A - works
Scenario C - does not work

Comment 11 Itamar Heim 2012-08-11 21:23:46 UTC
not sure why C is a regression. I'm pretty sure in 3.0 storage domain permissions had to be given at system level.

Comment 12 Oved Ourfali 2012-08-12 07:01:50 UTC
I did the following testing with the fix for bug #846300 (you can find a similar comment in that bug as well).

Added a new user, and gave him power user role on the DC.
Then, I logged in with it to the user portal, added a new VM, and added a new disk. It worked well.

One of the changes I did was to make the storage domain inherit the permissions from the DC, so looks like that was what solved your scenario, as PowerUser has permissions to create disks, and with my patches this permission also propogates to the storage domains.

Comment 13 Yair Zaslavsky 2012-08-12 09:05:10 UTC
Scenario C does not work at 3.0 as well, threfore is not a part of the regression (Just chedked on 3.0 setup) - a storage domain is created under SYSTEM, not under data center. A storage domain is associated to data center only using attach.
IMHO, changing this , even for the sake of creating storage domain is incorrect.

Comment 14 Oved Ourfali 2012-08-12 09:30:48 UTC
If A is not reporoduced, B is solved in bug #846300, and C won't be fixes, can we close this bug?


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