| Summary: | admin shall not be able to revoke its own role of "administrator" | ||
|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | Shveta <ssachdev> |
| Component: | aeolus-conductor | Assignee: | Scott Seago <sseago> |
| Status: | CLOSED ERRATA | QA Contact: | wes hayutin <whayutin> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.0.0 | CC: | akarol, asettle, athomas, cpelland, dajohnso, deltacloud-maint, dmacpher, hbrock, jlabocki, juwu, matt.wagner, morazi, slinaber, ssachdev, tzumainn |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
When an administrator revoked its own role, a blank page with an error message displayed:
"Insufficient privileges for the action"
The error message appeared because the user no longer hd permissions to view the page. This bug updates aeolus-conductor so that administrators can no longer revoke the role if there is only one administrator in the system. Users are re-directed to the account page after deleting their administrative permissions
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-12-04 14:57:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Shveta
2012-02-29 06:29:06 UTC
I *think* if the admin is not the *last* admin this should be ok.. but asking dev Yeah this sort of thing is tricky, since there are no 'magic' role names. There's nothing special about 'Administrator' vs 'Provider Administrator' other than it includes more privileges. In fact, roles are technically mutable objects, but for now we provide no UI to modify them. The 'insufficient privileges' error is because the user now no longer has privileges to view the current page (permissions list) Longer-term perhaps we should warn a user any tine he's revoking himself from _any_ privilege list -- but even that gets tricky once we have groups, etc. Do we have any idea how most other applications w/ role-based permissions handle the situation of users revoking their own rights? athomas, what's the desired functionality here, given the issues raised in comment 2? I'm assuming we have to allow users revoking their own rights -- we _could_ provide warnings/confirmations/etc but that requires implementing a two-step submittal process. A valid use case might be transferring rights to something. A pool admin adds another pool admin and then revokes his own permissions to that pool. This would trigger the sort of 'insufficient privileges' error shown above. In the instance where users are reducing their own privileges, how about using a flash message to confirm the successful removal, then putting them on a view which they will be permitted to see, like their own user details? That ought to stop the appearance of the 'insufficient privileges' error. Also, if it is practicable, it would be good to have a "You're about to revoke the only assignment of the Administrator role. Are you sure?" dialog. Patch on list: [PATCH conductor] bug 798516: prevent last admin deletion Pushed to master/1.1:
commit 8112e5705f11283bec7b6e064d6f14744a250c07
Author: Scott Seago <sseago>
Date: Wed Sep 5 19:36:36 2012 -0400
https://bugzilla.redhat.com/show_bug.cgi?id=798516
Don't allow deletion of admin permissions if there is only one admin left.
Upon permission removal, redirect user to /account if the user's
own permissions to that page have been revoked.
Signed-off-by: Tzu-Mainn Chen <tzumainn>
in build aeolus-conductor-0.13.3-1.el6cf *** Bug 828480 has been marked as a duplicate of this bug. *** Moving back to 'POST' -- we discovered a problem with the patch on F16. The new patch cleans up a conditional statement that was causing problems. [PATCH conductor] additional fix for 798516: conditional logic/ruby version behavior Back to MODIFIED: fix is in at 2f1db53842a91b42b82edc65b8fd3af621f94104 on master Cherry-picked onto 1.1:
commit a4067e9ab04e1372fd1bcd59fb1c1bf6622ec12c
Author: Scott Seago <sseago>
Date: Mon Sep 10 11:38:35 2012 -0400
additional fix for 798516: conditional logic/ruby version behavior
https://bugzilla.redhat.com/show_bug.cgi?id=798516
Apparently on f16/ruby 1.8, the conditional block with 'or' and 'not' is
not working as expected. I don't know if it's a ruby bug or something else
but it doesn't matter in this case -- using '!' and '||' is the right
way to do the conditional anyway.
(cherry picked from commit 2f1db53842a91b42b82edc65b8fd3af621f94104)
good 2 go in CFCE v1.1 2012-09-14.5 puddle [root@qeblade37 ~]# rpm -qa | grep aeolus | sort aeolus-all-0.13.7-1.el6cf.noarch aeolus-conductor-0.13.7-1.el6cf.noarch aeolus-conductor-daemons-0.13.7-1.el6cf.noarch aeolus-conductor-doc-0.13.7-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch rubygem-aeolus-image-0.3.0-12.el6.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 |