Bug 839319 - Permissions given to DataCenter level do not apply
Permissions given to DataCenter level do not apply
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Oved Ourfali
Tomas Dosek
infra, ux
: Regression, Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-07-11 10:58 EDT by David Jaša
Modified: 2015-09-22 09 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-12 06:44:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-07-11 10:58:02 EDT
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):

How reproducible:

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

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

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 11:18:16 EDT
(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 04:53:08 EDT
(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 14:53:47 EDT
Sounds similar to

But need to investigate this more .
Comment 7 RHEL Product and Program Management 2012-07-29 08:46:41 EDT
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 07:01:50 EDT
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 12:20:44 EDT
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 17:23:46 EDT
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 03:01:50 EDT
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 05:05:10 EDT
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 05:30:48 EDT
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.