Bug 1423881

Summary: [RFE]: fence_rhevm: Filter's scope to exclude privileged users
Product: Red Hat Enterprise Linux 7 Reporter: Irina Petrova <ipetrova>
Component: fence-agentsAssignee: Oyvind Albrigtsen <oalbrigt>
Status: CLOSED DUPLICATE QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: cluster-maint, juan.hernandez, mgrac, mjuricek, pablo.iranzo
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-26 15:05:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Irina Petrova 2017-02-17 15:06:00 UTC
Description of problem:

The patch below [1] introduces a peculiar behavior: when combined with the 'Filter: true' header (which is hard-coded by default) the super user doesn't have super privileges anymore, and it cannot see virtual machines it hasn't been given explicit permissions to.

In that sense, the 'admin@internal' (the RHV super user) has no longer all the permissions and as a result does not see all the VMs as it used to before the patch was merged. 

Currently, in order for the 'admin@internal' to see a VM, the 'UserRole' permission has to be added to the 'admin@internal' user for each relevant virtual machine. In a big environment that necessity combined with introducing the new behavior mid-version (the patch was added to version -47.el7_3.2 as a minor fix) presents two problems: (1) the 'surprise' element that would tempt people to 'fix' the code themselves in order to have the old behavior, and most importantly (2) the inconvenience of having have to add the 'UserRole' permissions for every virtual machine which is human-error prone (that is, it is extremely easy to miss/misconfigure VMs).

Given the said above, and that the patch was written to solve a non-privileged user problem (if I understand correctly), can we either (1) move the privileged users outside the scope of the Filter Header (as it is effectively removing their permissions), or (2) at least make it configurable, i.e. make possible to switch off and/or control the state of the Filter (true/false)?

~~~~~~~~~~~~~~~~
[1] Downstream:
~~~~~~~~~~~~~~~~
bz1287059-1-fence_rhevm-add-filter-header.patch
From 03eee868ec5f3a07024a6b7c65572e54238106c6 Mon Sep 17 00:00:00 2001
From: Rik Theys <Rik.Theys.be>
Date: Tue, 19 May 2015 13:24:09 +0200
Subject: [PATCH 1/2] fence_rhevm: Add Filter header

oVirt users who only have the UserRole role don't have enough privileges
to query the vm list, unless the Filter header is set to true.

See rhbz#1102801 for details.
---
 fence/agents/rhevm/fence_rhevm.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fence/agents/rhevm/fence_rhevm.py b/fence/agents/rhevm/fence_rhevm.py
index 427bed5..cf85689 100644
--- a/fence/agents/rhevm/fence_rhevm.py
+++ b/fence/agents/rhevm/fence_rhevm.py
@@ -87,7 +87,7 @@ def send_command(opt, command, method="GET"):
 	conn = pycurl.Curl()
 	web_buffer = StringIO.StringIO()
 	conn.setopt(pycurl.URL, url)
-	conn.setopt(pycurl.HTTPHEADER, ["Content-type: application/xml", "Accept: application/xml", "Prefer: persistent-auth"])
+	conn.setopt(pycurl.HTTPHEADER, ["Content-type: application/xml", "Accept: application/xml", "Prefer: persistent-auth", "Filter: true"])
 
 	if opt.has_key("cookie"):
 		conn.setopt(pycurl.COOKIE, opt["cookie"])
-- 
2.5.0

< snip >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~
[1] Upstream: 
~~~~~~~~~~~~~~~~
https://github.com/ClusterLabs/fence-agents/commit/03eee868ec5f3a07024a6b7c65572e54238106c6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Version-Release number of selected component (if applicable):

fence-agents-rhevm-4.0.11-47.el7_3.2.x86_64.rpm

Comment 1 Juan Hernández 2017-02-17 15:11:26 UTC
My suggestion about that is to add a '--filter true|false' option to the agent, so that users can configure it to their needs.

Comment 2 Pablo Iranzo Gómez 2017-02-17 15:25:13 UTC
(In reply to Irina Petrova from comment #0)
> Description of problem:
> 
> The patch below [1] introduces a peculiar behavior: when combined with the
> 'Filter: true' header (which is hard-coded by default) the super user
> doesn't have super privileges anymore, and it cannot see virtual machines it
> hasn't been given explicit permissions to.
> 
> In that sense, the 'admin@internal' (the RHV super user) has no longer all
> the permissions and as a result does not see all the VMs as it used to
> before the patch was merged. 
> 
> Currently, in order for the 'admin@internal' to see a VM, the 'UserRole'
> permission has to be added to the 'admin@internal' user for each relevant
> virtual machine. In a big environment that necessity combined with
> introducing the new behavior mid-version (the patch was added to version
> -47.el7_3.2 as a minor fix) presents two problems: (1) the 'surprise'
> element that would tempt people to 'fix' the code themselves in order to
> have the old behavior, and most importantly (2) the inconvenience of having
> have to add the 'UserRole' permissions for every virtual machine which is
> human-error prone (that is, it is extremely easy to miss/misconfigure VMs).
> 
> Given the said above, and that the patch was written to solve a
> non-privileged user problem (if I understand correctly), can we either (1)
> move the privileged users outside the scope of the Filter Header (as it is
> effectively removing their permissions), or (2) at least make it
> configurable, i.e. make possible to switch off and/or control the state of
> the Filter (true/false)?
> 


Based on the prior behaviour, which is in within the same major release, the default for the filtering should be 'false' so the behavior is not changed for the already existing deployments, but still, as Juan suggests allow to change it on the fencing agent.

Comment 5 Marek Grac 2017-03-01 16:09:00 UTC
We can add a new option --filter-header [true|false] with 'true' as a default, so it will follow current state. (fixed in https://bugzilla.redhat.com/show_bug.cgi?id=1287059)

imho this is problem on the RHEV-M side because there should be a way how to do such actions without information if i'm administrator or not.

Comment 6 Juan Hernández 2017-03-01 16:13:20 UTC
That is right, that is a RHV problem. In version 4.2 we will enable filtering by default for non admin users, see bug 1420310. However I think it is good idea to add the --filter-header option to the agent, so that users can enable/disable it at will, specially for versions of RHV older than 4.2.

Comment 7 Oyvind Albrigtsen 2017-04-26 15:05:35 UTC
This is fixedin bz#1422499.

*** This bug has been marked as a duplicate of bug 1422499 ***