Hide Forgot
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
This is similar but not identical to 788148. We need to either clarify this role's capabilities or tighten up the permissions.
moving version to 1.0.0 . version = found in version
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?
I don't believe this is a blocker, it's just a poorly documented part of the permission system. Moving to 1.1.0.
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.
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.
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.
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.
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