Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. admin can revoke its own role of Administrator 2. When revoked it says :insufficient Privileges for the action" but it actually revokes the role and then admin starts behaving like a normal user without any admin rights. 3. Actual results: Expected results: Additional info: rpm -qa|grep aeolus aeolus-conductor-0.8.0-38.el6.noarch aeolus-all-0.8.0-38.el6.noarch aeolus-conductor-daemons-0.8.0-38.el6.noarch aeolus-configure-2.5.0-15.el6.noarch rubygem-aeolus-image-0.3.0-10.el6.noarch rubygem-aeolus-cli-0.3.0-11.el6.noarch aeolus-conductor-doc-0.8.0-38.el6.noarch
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