Bug 1155935 - SELinux prevents glusterd from writing to socket_t file
Summary: SELinux prevents glusterd from writing to socket_t file
Keywords:
Status: CLOSED DUPLICATE of bug 1108448
Alias: None
Product: Fedora
Classification: Fedora
Component: glusterfs
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Kaleb KEITHLEY
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-23 08:33 UTC by Juanjo
Modified: 2014-10-27 13:49 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-27 13:49:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1108448 0 medium CLOSED selinux alerts starting glusterd in f20 2021-02-22 00:41:40 UTC

Internal Links: 1108448

Description Juanjo 2014-10-23 08:33:56 UTC
Description of problem:
The glusterd daemon does not have permission to write to the socket /var/run/glusterd.socket due to SELinux constraints. This is similar to the bug in 911480, but that report has no information about how to solve the problem.

How reproducible:
All servers I have have this problem. It seems to be randomly solved by running audit2allow, but sometimes the audit.log cannot be parsed by audit2allow and then I am clueless as how to fix it :-/

# sealert -l f7a6d843-eb7c-498b-887f-d5b414b205d2
SELinux is preventing /usr/sbin/glusterfsd from write access on the sock_file .

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that glusterfsd should be allowed write access on the  sock_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep glusterd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:glusterd_t:s0
Target Context                unconfined_u:object_r:var_run_t:s0
Target Objects                 [ sock_file ]
Source                        glusterd
Source Path                   /usr/sbin/glusterfsd
Port                          <Unknown>
Host                          kitaev.iff.csic.es
Source RPM Packages           glusterfs-3.5.2-1.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-189.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     kitaev.iff.csic.es
Platform                      Linux kitaev.iff.csic.es 3.16.6-200.fc20.x86_64 #1
                              SMP Wed Oct 15 13:06:51 UTC 2014 x86_64 x86_64
Alert Count                   2
First Seen                    2014-10-23 10:20:04 CEST
Last Seen                     2014-10-23 10:21:31 CEST
Local ID                      f7a6d843-eb7c-498b-887f-d5b414b205d2

Raw Audit Messages
type=AVC msg=audit(1414052491.576:1196): avc:  denied  { write } for  pid=22682 comm="glusterd" name="glusterd.socket" dev="tmpfs" ino=22404 scontext=system_u:system_r:glusterd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file permissive=0


type=SYSCALL msg=audit(1414052491.576:1196): arch=x86_64 syscall=connect success=no exit=EACCES a0=b a1=7fffcdf4fca0 a2=6e a3=7fffcdf4fc1c items=0 ppid=22681 pid=22682 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=glusterd exe=/usr/sbin/glusterfsd subj=system_u:system_r:glusterd_t:s0 key=(null)

Hash: glusterd,glusterd_t,var_run_t,sock_file,write

# ls -lZ /var/run/glusterd.socket 
srwxr-xr-x. root root unconfined_u:object_r:var_run_t:s0 /var/run/glusterd.socket

Comment 1 Juanjo 2014-10-23 08:50:26 UTC
Further messages go on with setattr access, as well.

Comment 2 Juanjo 2014-10-23 10:27:59 UTC
Seems cleaning up and purging the package and all the files in all the nodes, and reinstalling, redid the permissions that they were supposed to have. That is a bit disturbing.

Comment 3 Juanjo 2014-10-23 17:07:15 UTC
(In reply to Juanjo from comment #2)
> Seems cleaning up and purging the package and all the files in all the
> nodes, and reinstalling, redid the permissions that they were supposed to
> have. That is a bit disturbing.

Actually the error message disappeared, but it reappeared again after some time.

Comment 4 Kaleb KEITHLEY 2014-10-27 13:49:04 UTC

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


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