Bug 790699

Summary: Non admin user is able to user Default zone after the " Zone Global User " role is revoked
Product: [Retired] CloudForms Cloud Engine Reporter: Shveta <ssachdev>
Component: aeolus-conductorAssignee: Scott Seago <sseago>
Status: CLOSED CURRENTRELEASE QA Contact: Dave Johnson <dajohnso>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, athomas, dajohnso, deltacloud-maint, hbrock, jlaska, psharma, ssachdev
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-13 19:48:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
zone_roles none

Description Shveta 2012-02-15 08:39:17 UTC
Created attachment 562163 [details]
zone_roles

Description of problem:


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


How reproducible:


Steps to Reproduce:
1. Created a user shveta .
2. Gave the role of "Zone global user"
3. created a zone from admin .. shveta is able to use that zone , launch instance etc
  
4. Revoked that role and given the role of "Zone creator"
User can now create its own zones but can't see zones created by admin

5. However "Default"zone is still accessible
Actual results:


Expected results:


Additional info:

rpm -qa|grep aeolus
aeolus-conductor-doc-0.8.0-27.el6.noarch
aeolus-conductor-daemons-0.8.0-27.el6.noarch
aeolus-configure-2.5.0-13.el6.noarch
rubygem-aeolus-cli-0.3.0-8.el6.noarch
aeolus-all-0.8.0-27.el6.noarch
aeolus-conductor-0.8.0-27.el6.noarch
rubygem-aeolus-image-0.3.0-7.el6.noarch

Comment 1 Hugh Brock 2012-02-22 18:10:11 UTC
This is similar but not identical to 788148. We need to either clarify this role's capabilities or tighten up the permissions.

Comment 2 wes hayutin 2012-02-22 23:45:55 UTC
moving version to 1.0.0 .  version = found in version

Comment 3 Scott Seago 2012-02-28 05:42:59 UTC
I think what's going on is that you didn't remove the user's permissions on the 'default' zone. Right now, all users by default get access to the default zone.

What are the "default" permissions desired for 1.0? Right now we're doing two things:
1) adding 'zone global user' (I'm assuming we _don't_ want to continue this)
2) adding 'default zone' user permissions.

Do we still want to do 2? Or do we want to require admins to manually add users to the right environments and zones, since the 'default' zone may not make sense to most users?

Comment 6 Hugh Brock 2012-03-07 18:32:19 UTC
I don't believe this is a blocker, it's just a poorly documented part of the permission system. Moving to 1.1.0.

Comment 7 Scott Seago 2012-03-08 17:37:23 UTC
We can revisit in 1.1 time frame, but I suspect this is still NOTABUG as written. Post-1.0 we need to revisit the 'default user permissions' question and provide a UI around what new users get by default, in addition to the other open enhancement BZ around adding UI to the user profile page to list all of a user's permission grants -- but even then, those are a separate feature to add, not really related here, other than it would prevent this sort of thing from happening in a real-life situation.

Comment 8 Scott Seago 2012-08-28 03:54:24 UTC
Please revisit in light of comment 3 above -- note that on the master branch at least, you can now see the permission grants for a user, so this will help track down any remaining permissions after revoking global ones, etc.

Comment 9 Angus Thomas 2012-08-29 10:10:41 UTC
We should continue to assign permissions to all users on the default zone.

In instances where that isn't the Administrators' intent, they'll have to act to modify the permissions. However, they would be required to do so anyway, if there were no zone permissions assigned by default.

Comment 10 Scott Seago 2012-08-29 13:53:48 UTC
So, once we confirm from QE that the user could access the Default zone because the user's permissions to the default zone had not yet been removed, we can close this as NOTABUG.

Comment 11 pushpesh sharma 2012-09-18 10:36:24 UTC
User could access the Default zone but can not add/edit any parameter of it. As the default role grant for any new user Global HWP user So it is not able to add/delete image/blueprint.As far as granting some access and revoking it is concerned. I tried the following:-
* Assign the user Global Cloud Resourse Zone Administartor along with default Global HWP user.
*Add/delete images/blueprint,edit name of zone ---> wokred prefectly
* Revoked the same Global Cloud Resourse Zone Administartor roles from the user,
*Add/delete images/blueprint,edit name of zone ---> not sufficient permissions

So I feel there are no symptom of as bug as far as thsi scenario is concerned. 
Marking as verfied.Verified on:-

[root@dhcp201-113 ~]# rpm -qa|grep aeolus
aeolus-conductor-doc-0.13.7-1.el6cf.noarch
aeolus-all-0.13.7-1.el6cf.noarch
rubygem-aeolus-cli-0.7.1-1.el6cf.noarch
aeolus-configure-2.8.6-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-0.13.7-1.el6cf.noarch
aeolus-conductor-daemons-0.13.7-1.el6cf.noarch