Bug 1387484

Summary: samba fails to connect to glusterd.socket when selinux is set to enforcing
Product: Red Hat Gluster Storage Reporter: Vivek Das <vdas>
Component: sambaAssignee: Michael Adam <madam>
Status: CLOSED WORKSFORME QA Contact: Vivek Das <vdas>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rhgs-3.2CC: amukherj, anoopcs, gdeschner, nchilaka, rhs-smb, rtalur, vdas
Target Milestone: ---Keywords: ZStream
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: 2019-12-12 21:54:10 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:

Description Vivek Das 2016-10-21 03:16:50 UTC
Description of problem:
samba fails to connect to glusterd.socket when selinux is set to enforcing.

type=AVC msg=audit(1476974134.111:87217): avc:  denied  { write } for  pid=31486 comm="smbd" name="glusterd.socket" dev="tmpfs" ino=11876158 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:glusterd_var_run_t:s0 tclass=sock_file

Version-Release number of selected component (if applicable):
samba-client-4.4.6-2.el7rhgs.x86_64
glusterfs-client-xlators-3.8.4-2.el7rhgs.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Create a 4 node gluster cluster with ctdb
2.Enable volfile setup in smb.conf with unix+ socket (unix+/var/run/glusterd.socket tcp+<valid hostname>)
3.reload the smb config file (smbcontrol smbd reload-config)
4.kill glusterd in one of the server node
5.mount in windows using "net use" provide the ip of the server where glusterd is stopped

Actual results:
samba fails to connect to glusterd socket

Expected results:


Additional info:

Comment 3 Raghavendra Talur 2016-11-09 09:33:09 UTC
We need to refer to the RHEL bug which will add the selinux rule.

Comment 10 Yaniv Kaul 2019-12-12 21:54:10 UTC
Closing - we have not touched it for years, but we believe it is fixed.
If it reproduces - please reopen.