Bug 1014000

Summary:	Cluster can't fence node after fence_node has fenced.
Product:	Red Hat Enterprise Linux 6	Reporter:	Daniele <dconsoli>
Component:	fence-agents	Assignee:	Marek Grac <mgrac>
Status:	CLOSED ERRATA	QA Contact:	Cluster QE <mspqa-list>
Severity:	medium	Docs Contact:
Priority:	high
Version:	6.4	CC:	acathrow, cluster-maint, djansa, fdinitto, mgrac, mjuricek, tlavigne
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	fence-agents-3.1.5-35.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1022528 (view as bug list)		Environment:
Last Closed:	2013-11-21 07:19:48 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:
Bug Depends On:
Bug Blocks:	1022528

Description Daniele 2013-10-01 08:52:14 UTC

Description of problem:
-> If the first fencing is done by the cluster itself, the /tmp/suds directory will be created with the correct SELinux context (fenced_tmp_t). Fencing will work fine, even if further fencing is triggered via fence_node command.

-> However, if the first fencing happens via fence_node, /tmp/suds/ will be created with wrong SELinux context (user_tmp_t). This one fence itself will work, but any further fence attempts will work ONLY via fence_node. Normal cluster fencing will fail.

-> If the latter scenario happens, deleting /tmp/suds/ directory and then triggering cluster fencing will reset the directory with the correct context.

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

How reproducible:
100% of the times on customer's setup

Steps to Reproduce:
1. let the cluster fence
2. check permissions on /tmp/suds (SELinux)
3. try to fence via cluster fence or fence_node

1. fence via fence_node
2. check permissions on /tmp/suds(SELinux)
3. try to fence via cluster fence or fence_node

Actual results:
if the first fencing happens via fence_node, /tmp/suds/ will be created with wrong SELinux context (user_tmp_t). This one fence itself will work, but any further fence attempts will work ONLY via fence_node. Normal cluster fencing will fail.

Expected results:
Fence should work via any method, indipendently from which method has been used first.

Additional info:
This is a cluster on VMWare. This shouldn't change anything though, as the problem seems to be in how /tmp/suds is set.

Comment 2 Fabio Massimo Di Nitto 2013-10-03 06:05:53 UTC

(In reply to Daniele from comment #0)
> Description of problem:
> -> If the first fencing is done by the cluster itself, the /tmp/suds
> directory will be created with the correct SELinux context (fenced_tmp_t).
> Fencing will work fine, even if further fencing is triggered via fence_node
> command.
> 
> -> However, if the first fencing happens via fence_node, /tmp/suds/ will be
> created with wrong SELinux context (user_tmp_t). This one fence itself will
> work, but any further fence attempts will work ONLY via fence_node. Normal
> cluster fencing will fail.
> 
> -> If the latter scenario happens, deleting /tmp/suds/ directory and then
> triggering cluster fencing will reset the directory with the correct context.
> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> 100% of the times on customer's setup
> 
> Steps to Reproduce:
> 1. let the cluster fence
> 2. check permissions on /tmp/suds (SELinux)
> 3. try to fence via cluster fence or fence_node
> 
> 1. fence via fence_node
> 2. check permissions on /tmp/suds(SELinux)
> 3. try to fence via cluster fence or fence_node
> 

Marek, what is creating /tmp/suds? hardcoded directories in /tmp are considered a security issue since they are predictable and can be used for symlinks attacks of different kind. Either change that to be a mktemp call or drop it completely.

As for the selinux, this bug should be eventually reassigned to selinux-policy

Comment 3 Marek Grac 2013-10-03 14:08:47 UTC

This file is created by SOAP library (vmware_soap, ovh) - it is not a problem to put it into different directory.

Comment 4 Fabio Massimo Di Nitto 2013-10-03 17:15:54 UTC

(In reply to Marek Grac from comment #3)
> This file is created by SOAP library (vmware_soap, ovh) - it is not a
> problem to put it into different directory.

Ok anything that uses /tmp _must_ use mktemp for a temporary dir. That would avoid both the possible security problem and selinux permission issues.

Comment 10 errata-xmlrpc 2013-11-21 07:19:48 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1562.html