| Summary: | "global provider user" is unable to view the provider accounts | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | Rehana <redakkan> | ||||||
| Component: | aeolus-conductor | Assignee: | Scott Seago <sseago> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | wes hayutin <whayutin> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 1.0.0 | CC: | akarol, cpelland, dajohnso, deltacloud-maint, hbrock, juwu, morazi, psharma, ssachdev, sseago | ||||||
| Target Milestone: | rc | Keywords: | Triaged, ZStream | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: |
The “Cloud Resource Provider” page requires edit permissions, which denies users with access to view the page. This update provides these users to a read-only version of the page.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 819944 (view as bug list) | Environment: | |||||||
| Last Closed: | 2012-12-04 15:01:56 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 819944 | ||||||||
| Attachments: |
|
||||||||
|
Description
Rehana
2012-03-29 11:57:45 UTC
Created attachment 573649 [details]
ss1
Hmm. I noticed this a couple days ago, but it wasn't obvious initially how to resolve it. The problem is that when we designed the UI we decided that, for providers (and _only_ providers), the default view was to be the 'edit' page. As a result, you can only get to the provider details if you have permission to edit the provider. Possible solutions: 1) fix the UI such that Providers has a proper view page that links to 'edit' as appropriate (like we do everywhere else) 2) keep the UI as-is, but change permissions to allow 'view only' users access to the 'edit' page (with plenty of comments to indicate that we know it's deliberate) but hide the 'save' button from these users I prefer 1) longer-term, but 2) would be a quicker fix updating the scenario observed for 'object level permissions' also
1. create a user with "global image admin" role
2. given "provider user" role('object level permissions') observed that when tried to access the provider it displayed "'You have insufficient privileges to perform the selected action"
Added this to cover the 'object level permissions' also
We'll do fix #2 (comment 2) for z-stream, fix properly in 1.1.0 Patch posted at: https://fedorahosted.org/pipermail/aeolus-devel/2012-May/010559.html For provider accounts, the 'edit' action doubles as the 'show' page. This meant we were requiring modify privileges on the provider to even see the provider pages. This patch relaxes the checking to reqiure only view permissions, and in the views we hide the edit/modify actions from users that don't have the higher privileges, and the form elements are made read-only. Pushed to master with: c8e2f50fcc10c4183d798fa1625d525a8c4b89d2 1. A user with "Global Provider User" role is able to view provider page but not able to see various provider account.(New/edit both are hidden).(expectation matched). 2. A user with object level(say here object is ec2-us-east) "Provider User" role is able to view only that provider.Again this user is not able to see various provider account.(New/edit both are hidden).(expectation matched). Verified On:- [root@dhcp201-113 ~]# rpm -qa|grep aeolus rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-all-0.13.8-1.el6cf.noarch aeolus-conductor-0.13.8-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.noarch aeolus-conductor-daemons-0.13.8-1.el6cf.noarch aeolus-conductor-doc-0.13.8-1.el6cf.noarch Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-1516.html |