Hide Forgot
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.
(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
This file is created by SOAP library (vmware_soap, ovh) - it is not a problem to put it into different directory.
(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.
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