Red Hat Bugzilla – Bug 1187777
RBAC: Group context switching affecting provisioning best-fit placement, quota and group ownership
Last modified: 2016-04-15 05:07:46 EDT
Created attachment 986231 [details] group tagging Description of problem: A tenant user group with tagged with tenant_environment => 'dev' provisions a VM. Immediately he/or she switches their group context so that they are in a group with tenant_environment => 'stress' provisions a VM. During best-fit placement the RBAC that is applied is not the group that is currently in context so best-fit fails to find a suitable host. The same thing happens at the end of provisioning when owner and group is assigned as it uses the current group context at the time of execution. So that effectively the Dev VM is trying to be placed on 'stress' tagged clusters and the group owner of the vm is set to the stress group. Version-Release number of selected component (if applicable): 5.3.2.6.20150108100920_387a856 How reproducible: Always! Steps to Reproduce: 1. Create a tag category called 'tenant_environment' 2. Create 2 tags in that category called 'dev'=>'Development' and 'prod'=>.Produciton' 3. Tag a cluster, Host(s), Datastore(s) and a template with 'dev' 4. Tag a different cluster, Host(s), Datastore(s) and template with 'prod' 5. Create a self-service role with 'template access restrictions' set to 'none' 6. Create a group from ldap that has a tag filter of 'dev' 7. Create a group from ldap that has a tag filter of 'prod' 7. Ensure that the user is a member of each group 8. Log in as the user and ensure that he is a member of group 'dev' 9. Kick off a provision job that utilizes :placement_auto => true 10. Immediately group context switch to the 'prod' group 11. Kick off a provision job that utilizes :placement_auto => true Actual results: During best fit because the users context or 'user.current_group' has been switched the message no eligible hosts error is found for the dev group deployment. Also the group ownership is set to the current_group context versus the group context present at the time the request is submitted as well as quota is not correctly calculated since the current group has been switched. Expected results: The miq_request object should retain the group information at the time of submission versus being dynamic in nature thus allowing the provision job to complete all the way through as intended. Additional info:
Issue reproduced. Overall strategy determined. There are quite a few areas in the code that overlap with this, so still working through best way to minimize code change.
getting second fix over into code base to better get grasp of where owner and requester are set.
New commit detected on manageiq/master: https://github.com/ManageIQ/manageiq/commit/f2ab91ed704bacd83bfd344d8ef59ff22752b4cc commit f2ab91ed704bacd83bfd344d8ef59ff22752b4cc Author: Keenan Brock <kbrock@redhat.com> AuthorDate: Tue Mar 3 09:46:38 2015 -0500 Commit: Keenan Brock <kbrock@redhat.com> CommitDate: Wed Mar 18 11:49:14 2015 -0400 set request’s owner.current_group owner is loaded from options[:owner_email] This also loads owner_group from options[:owner_group] https://bugzilla.redhat.com/show_bug.cgi?id=1187777 vmdb/app/models/mixins/miq_provision_mixin.rb | 11 ++- vmdb/spec/factories/user.rb | 5 ++ .../spec/models/mixins/miq_provision_mixin_spec.rb | 78 ++++++++++++++++++++++ 3 files changed, 93 insertions(+), 1 deletion(-) create mode 100644 vmdb/spec/models/mixins/miq_provision_mixin_spec.rb
https://github.com/ManageIQ/manageiq/pull/4370
https://github.com/ManageIQ/manageiq/pull/4403
https://github.com/ManageIQ/manageiq/pull/4408
I performed all the following steps exactly as I did on 5.4.3 and it worked correctly. I manually modified a user in rails console: u = User.first g1 = MiqGroup.first g2 = MiqGroup.last u.update_attributes(:current_group => g1, :miq_groups => [g1, g2]) I setup the environment as described. Starting with a group that allowed me to provision a VM, I started a provision request. Immediately I toggled "Change Group ->" to the group that does not allow the user to provision on that host. This had no impact on the request and the VM was created as requested. User is jteehan/smartvm It should be noted that upon completion, the user did not have access to that VM until switched back to a Group which did allow access. I don't see that the 5.4.3 issue has been reopened so I'm moving this to verified.
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. https://access.redhat.com/errata/RHSA-2015:2551
*** Bug 1212071 has been marked as a duplicate of this bug. ***