Bug 1394283 - [CFME 5.7 beta] Provisioning notifications are not RBAC-compliant with regard to group membership
Summary: [CFME 5.7 beta] Provisioning notifications are not RBAC-compliant with regard...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.8.0
Assignee: Šimon Lukašík
QA Contact: Shveta
URL:
Whiteboard: notification
Depends On:
Blocks: 1397465
TreeView+ depends on / blocked
 
Reported: 2016-11-11 14:57 UTC by Peter McGowan
Modified: 2017-06-12 17:54 UTC (History)
7 users (show)

Fixed In Version: 5.8.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1397465 (view as bug list)
Environment:
Last Closed: 2017-06-12 17:54:09 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


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