Bug 1014000 - Cluster can't fence node after fence_node has fenced.
Cluster can't fence node after fence_node has fenced.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fence-agents (Show other bugs)
6.4
x86_64 Linux
high Severity medium
: rc
: ---
Assigned To: Marek Grac
Cluster QE
:
Depends On:
Blocks: 1022528
  Show dependency treegraph
 
Reported: 2013-10-01 04:52 EDT by Daniele
Modified: 2013-11-21 02:19 EST (History)
7 users (show)

See Also:
Fixed In Version: fence-agents-3.1.5-35.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1022528 (view as bug list)
Environment:
Last Closed: 2013-11-21 02:19:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniele 2013-10-01 04:52:14 EDT
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 02:05:53 EDT
(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 10:08:47 EDT
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 13:15:54 EDT
(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 02:19:48 EST
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

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