Bug 765893 - Pool access controls not working.. able to launch w/o access
Summary: Pool access controls not working.. able to launch w/o access
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
Assignee: Scott Seago
QA Contact: wes hayutin
URL: https://qeblade31.rhq.lab.eng.bos.red...
Whiteboard:
Depends On:
Blocks: ce-sprint
TreeView+ depends on / blocked
 
Reported: 2011-12-09 16:14 UTC by wes hayutin
Modified: 2012-01-26 12:26 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-13 19:25:19 UTC


Attachments (Terms of Use)

Description wes hayutin 2011-12-09 16:14:51 UTC
Description of problem:
Pool access controls not working.. able to launch w/o access

1. create a pool 
2. create a non admin user
3. verify the user does not have access to the pool here
/conductor/pools/2?details_tab=permissions&only_tab=true

in another browser log in as user.. and launch an instance 
works .. when it should not...

Comment 1 wes hayutin 2011-12-09 16:15:24 UTC
[root@qeblade31 yum.repos.d]# rpm -qa | grep aeolus
aeolus-conductor-daemons-0.7.0-4.el6.noarch
aeolus-conductor-doc-0.7.0-4.el6.noarch
rubygem-aeolus-cli-0.2.0-3.el6.noarch
rubygem-aeolus-image-0.2.0-1.el6.noarch
aeolus-all-0.7.0-4.el6.noarch
aeolus-configure-2.4.0-3.el6.noarch
aeolus-conductor-0.7.0-4.el6.noarch

Comment 2 Scott Seago 2011-12-13 15:58:18 UTC
Currently we grant users blanket permissions across all pools as one of the default roles we grant all users. I'm still not entirely sure why we do that, but it may have been a workaround prior to adding a functional permissions UI.

You can verify this if you look at the 'Global Role Grants' tab under Users -- if the non-admin user has 'Pool Global User' assigned, then things are working properly.

That said, it looks like it's time to stop assigning users this role by default. Unless someone objects, I'll fix this issue by removing that role from the default user settings.

Comment 3 wes hayutin 2011-12-13 19:25:19 UTC
sure... enough if the user has global pool access they still have access.
When global is removed and explicit access is not granted.. the user does not have access..

very good..
closing


Note You need to log in before you can comment on or make changes to this bug.