Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Create a user with only "Global image administrator" role 2.login to conductor as "Global image administrator" 3.Try creating a new image (from upload or URL option) 4.Try Importing an image from provider Actual results: User was able to add image to provider @step 3, but the user is unable to import any images even though the "Cloud" has valid provider accounts. It displayed the error "Images cannot be imported, as no provider accounts are currently enabled for this environment" Expected results: As the name says "Global image administrator" user should be allowed to do all the image operation. Additional info: rpm -qa | grep aeolus aeolus-conductor-0.8.3-1.el6.noarch aeolus-conductor-daemons-0.8.3-1.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-configure-2.5.2-1.el6.noarch aeolus-all-0.8.3-1.el6.noarch rubygem-aeolus-cli-0.3.1-1.el6.noarch aeolus-conductor-doc-0.8.3-1.el6.noarch
As we had discussed earlier in an email thread, this is largely a requirements issue. Current behavior is by design, but there's a reasonable case to make this change (also a reasonable case to keep as-is). Pasting message in here... I was talking to Angus about this yesterday, and there are really 3 different options we can take here. First, to clarify why import is different -- the concern was that with import, the user importing potentially has access to see all of the private images in the provider account (even ones not related to aeolus), so there is some reason to consider requiring additional permissions on the account. With build/push we're limited to the images we already know about in the environment/cloud. On the other hand, since we're already limited to the provider accounts in the environment/cloud, it may be reasonable to not require explicit account permissions here, as long as we're clear in documentation that the image admin can potentially see a list of all the private images (even those not imported into conductor) in the accounts associated with the environment/cloud. Basically this is less of a bug issue than it is a requirements clarification. As such, we'll need to consider PM input as well, in determining which approach to take. So here are the options I mentioned to Angus yesterday: 1) remove the provider account access restriction: image admins (both global and cloud-level) will be able import any image in any account in the cloud/environment 2) keep the restriction but add global account view to global image admins: for cloud-level admins this means they have to be individually added to the accounts, but global image admins will not need it 3) keep it as-is. import should be less commonly-needed than build, and we want to ensure proper access controls around provider account private resources Yesterday, Angus was concerned that we really had time to add this into the 1.0 time frame (assuming we took 1) or 2) -- obviously 3) wouldn't be a problem). Again, in addition to the 'is it a blocker?' question, there's the more fundamental requirements question, since at this point, any of the three options look like valid approaches, depending on how paranoid we want to be on access control vs. ease-of-use. Scott
Having discussed with QE, we should move ahead with option 2 above.
Patch is on list here: https://fedorahosted.org/pipermail/aeolus-devel/2012-May/010600.html For an existing installation you've got to run 'rake db:upgrade' to see the updated role definition. For a new install, the updates are in seeds.rb
commit 65c7767d226206d366eb423d3aeeefbfa9bca8e0 Author: Scott Seago <sseago> Date: Tue May 29 14:19:58 2012 -0400 Bug 807745 add 'use provider accounts' to global image admin role https://bugzilla.redhat.com/show_bug.cgi?id= 807745 Image admin role has been augmented to include view and use permissions on provider accounts. This allows global image admins to import images from any provider account. To see the changes you need to run 'rake dc:upgrade' which performs the necessary data upgrade to get the role modification. The upgrade is currently implemented inline in the rake task -- the intent is for this task to eventually run a set of upgrade scripts from a dedicated 'upgrades' directory, but the infrastructure for that is not yet set up.
Global image admin is able to import image. verified on rpm -qa | grep aeolus rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-conductor-daemons-0.13.8-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch aeolus-conductor-doc-0.13.8-1.el6cf.noarch aeolus-all-0.13.8-1.el6cf.noarch aeolus-conductor-0.13.8-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.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