Bug 820537 - Object level permission " Provider Administrator" breaks the permission to view providers
Object level permission " Provider Administrator" breaks the permission to vi...
Status: CLOSED CURRENTRELEASE
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
Unspecified Unspecified
high Severity medium
: rc
: ---
Assigned To: Tzu-Mainn Chen
Rehana
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-10 06:29 EDT by Rehana
Modified: 2012-12-13 14:50 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-13 14:50:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rehana 2012-05-10 06:29:51 EDT
Description of problem:

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

How reproducible:

Steps to Reproduce:
1.Create a new user say 'user A' with "global profile administrator" role(with default role global profile user)
2.give rhevm "Provider administrator" role(object level) to 'user A'
3.now login as 'user A ' from different browser
4. Access Cloud resource provider --> 'user A' will be able to view the rhevm provider
5. give vsphere  "Provider administrator" role(object level) to the 'user A'
6. Access Cloud resource provider --> 'user A' will be able to view the rhevm and vsphere providers
7. Now revoke the "Provider administrator" role of rhevm provider
  
Actual results:
User A is not able to view the 'vsphere' provider even though the user still have 'provider administrator' role to vsphere

Expected results:
User A should be able to view the provider/s to which the user has provider administrator role

Additional info:

rpm -qa | grep aeolus
aeolus-conductor-0.8.13-1.el6_2.noarch
aeolus-configure-2.5.3-1.el6.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
rubygem-aeolus-cli-0.3.1-1.el6.noarch
aeolus-all-0.8.13-1.el6_2.noarch
aeolus-conductor-doc-0.8.13-1.el6_2.noarch
aeolus-conductor-daemons-0.8.13-1.el6_2.noarch
Comment 1 Rehana 2012-05-10 12:30:34 EDT
updating the step now..

make sure that you have an active session for the 'user A' while granting/revoking the permissions.
Comment 2 Scott Seago 2012-05-10 12:59:12 EDT
So in the index action of ProvidersController there is code there such that when a user navigates to /providers (with no provider specified) we use the "current" provider ID stored in the session. The first time the user accesses this action we grab the first provider the user has permission to access. After that it's remembered in the session. Basically after we grab the provider from the session, we need to check to see if @provider exists in @providers -- if not, we set @provider back to nil and it will pick a new provider from @providers in the already-existing 'ensure' block
Comment 5 Dave Johnson 2012-08-08 13:54:32 EDT
Retesting this is currently blocked by bug 843671
Comment 6 Tzu-Mainn Chen 2012-08-10 11:40:26 EDT
This bug should be fixed with the advent of the new provider index page.
Comment 7 Rehana 2012-09-24 06:15:11 EDT
Observed that the user is allowed to view the other providers, tested with active sessions

Moving to verified on

rpm -qa | grep aeolus
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-daemons-0.13.8-1.el6cf.noarch
rubygem-aeolus-cli-0.7.1-1.el6cf.noarch
aeolus-conductor-doc-0.13.8-1.el6cf.noarch
aeolus-all-0.13.8-1.el6cf.noarch
aeolus-conductor-0.13.8-1.el6cf.noarch
aeolus-configure-2.8.6-1.el6cf.noarch

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