Bug 765893

Summary:	Pool access controls not working.. able to launch w/o access
Product:	[Retired] CloudForms Cloud Engine	Reporter:	wes hayutin <whayutin>
Component:	aeolus-conductor	Assignee:	Scott Seago <sseago>
Status:	CLOSED WORKSFORME	QA Contact:	wes hayutin <whayutin>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	1.0.0	CC:	akarol, deltacloud-maint, ssachdev, sseago
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://qeblade31.rhq.lab.eng.bos.redhat.com/conductor/pools/2?details_tab=permissions&only_tab=true
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-13 19:25:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	744194

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