Bug 1394283

Summary:	[CFME 5.7 beta] Provisioning notifications are not RBAC-compliant with regard to group membership
Product:	Red Hat CloudForms Management Engine	Reporter:	Peter McGowan <pmcgowan>
Component:	Appliance	Assignee:	Šimon Lukašík <slukasik>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Shveta <sshveta>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.7.0	CC:	abellott, cpelland, dajohnso, jhardy, mkanoor, obarenbo, tfitzger
Target Milestone:	GA	Keywords:	TestOnly
Target Release:	5.8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	notification
Fixed In Version:	5.8.0.0	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1397465 (view as bug list)		Environment:
Last Closed:	2017-06-12 17:54:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	CFME Core	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1397465

Description Peter McGowan 2016-11-11 14:57:59 UTC

Description of problem:
The current implementation of notifications isn't RBAC-compliant with regard to group membership. Provisioning-related notifications get sent to all members of a tenant. If a tenant contains two groups, each with a role that specifies VM & Template Access Restriction of 'Only User or Group Owned' or 'Only User Owned', then these users see notifications about VMs provisioned by other groups, that they have no access to.

Version-Release number of selected component (if applicable):
5.7.0.10-beta3.20161109111947_9a61b18 

How reproducible:
Every time

Steps to Reproduce:
1. Create a new role that has a VM & Template Access Restriction of 'Only User or Group Owned'
2. Create two new groups in the same tenant, each with this role. 
3. Create a user in each group. 
4. Provision a VM as one user, then login as the other user.

Actual results:
The second user sees notifications about the first user's provisioning operation, even though they have no access to the resulting VM

Expected results:
The provisioning-related messages should only be seen by the requester and owner of the VM.

Additional info:

Comment 2 Greg McCullough 2016-11-11 15:33:21 UTC

I think this applies to more notifications then just those initiated from automate.  Sending to appliance team to evaluate.

Comment 3 Šimon Lukašík 2016-11-21 15:39:50 UTC

https://github.com/ManageIQ/manageiq/pull/12771

Comment 4 CFME Bot 2016-11-22 15:15:52 UTC

New commit detected on ManageIQ/manageiq/euwe:
https://github.com/ManageIQ/manageiq/commit/95b74a8a55fcbd5ebd93717eb58775b4c9ea211f

commit 95b74a8a55fcbd5ebd93717eb58775b4c9ea211f
Author:     Gregg Tanzillo <gtanzill>
AuthorDate: Tue Nov 22 08:51:42 2016 -0500
Commit:     Oleg Barenboim <chessbyte>
CommitDate: Tue Nov 22 10:13:49 2016 -0500

    Merge pull request #12771 from isimluk/rhbz#1394283
    
    Emit notifications only when user is authorized to see concerned object
    (cherry picked from commit 538b938dd4b81c5aff0347b9787da55622f97d3e)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1394283

 app/models/notification.rb                            |  5 +++++
 spec/lib/miq_automation_engine/miq_ae_service_spec.rb |  5 ++++-
 spec/models/notification_spec.rb                      | 13 +++++++++++++
 3 files changed, 22 insertions(+), 1 deletion(-)

Comment 6 Shveta 2017-04-29 00:38:28 UTC

To recreate :
1) Created a role with VM & Template Access Restriction of 'Only User or Group Owned'
2) Created two groups under same tenant with the above role
3) Created two users belonging to each group.
4) Login as user 1(shveta/redhat) and provision an amazon instance .
5) Neither user 1 nor user 2 get notification.
6) Changed the role to VM& template restriction = None , user can now see all notifications, new or earlier ones too .

Appliance : https://10.8.198.161

Comment 7 Šimon Lukašík 2017-05-02 08:28:40 UTC

Wow, nice find, Shveta!

However, assuming everything else works as expected, I think this exception doesn't earn a `blocker` status. I think it could be solved in separate bz.

Comment 8 Šimon Lukašík 2017-05-03 11:35:21 UTC

Interestingly, the 5.7 version of this (bug 1397465) was verified. I searching what changed since then.

Comment 9 Šimon Lukašík 2017-05-04 09:02:03 UTC

This is currently blocked by other bug (set ownership not working for templates). That is however blocker by other bug in master (set ownership view broken by recent gtl refactoring).

Comment 11 Shveta 2017-05-09 03:37:07 UTC

Checked again . 
Working as expected.

Comment 12 Shveta 2017-05-09 03:37:41 UTC

Verified in 5.8.0.13-rc2.20170502165848_0f98658