Selinux php-fpm httpd and mariadb socket connection

Support
1

Edit note for reference
Installing the EL Repo MariaDB 10.5 installs a package “mysql-selinux” and the default repo (epel-release?) allows the necessary communications and php-fpm can connect to mariadb fine. It seems like maybe the MariaDB repo package is missing this functionality. I would have installed the EL repo MariaDB on my AL 8.6 system, but removed it and went with the MariaDB repo for regular operation.
I found the source for “mysql-selinux” here and it’s not trivial like my “fix”:

this package is NOT installed on my 8.6 system which works…

I have a system running fine with SELinux enabled on AlmaLinux 8.6. I’m using stock AL 8.6 Apache/httpd (2.4.37 I think) and php from Remi’s Repo:
https://rpms.remirepo.net/wizard/

I initially installed MariaDB 10.4 directly from the MariaDB repo using these instructions:

SELinux is enabled and I don’t believe I made any customizations specifically for php-fpm to connect to the mysql.sock socket/process. I recently upgraded to MariaDB 10.6, again from the MariaDB repo, and everything continued working as it always did. For reference my “working” validation is using phpMyAdmin configured to connect through a local socket.

I’ve installed my AlmaLinux 9 VM with stock Apache/httpd (2.4.51 I think). I installed MariaDB 10.6 from the same repo with the same instructions. Now, I’m getting a denial from SELinux for php-fpm (running as httpd_t) trying to connect to the /var/lib/mysql/mysql.sock process (running as unconfinsed_service_t). This denial prevents the connection and subsequent login from phpMyAdmin (running under the php-fpm service):

time->Mon Sep 26 22:14:07 2022
type=PROCTITLE msg=audit(1664244847.002:83): proctitle=7068702D66706D3A20706F6F6C20777777
type=SYSCALL msg=audit(1664244847.002:83): arch=c000003e syscall=42 success=no exit=-13 a0=5 a1=7ffc156c46b0 a2=1b a3=557032b785a0 items=0 ppid=706 pid=738 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="php-fpm" exe="/opt/remi/php74/root/usr/sbin/php-fpm" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1664244847.002:83): avc:  denied  { connectto } for  pid=738 comm="php-fpm" path="/var/lib/mysql/mysql.sock" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0

This ONLY shows up on my AL 9 install, AL 8.6 does not report this denial and allows the connection and subsequent login. I checked the file and process SELinux contexts and they are the same between 8.6 and 9. I’ve also tried different php-fpm versions, including the same between my 8.6 install and 9 (both php 7.4 from Remi). I’ve tried running the fpm pool under apache:apache and under my phpMyAdmin user with group apache.

Any advice on how to track this down? I can “fix” the SELinux denial with the following policy, but it allows httpd to connect to any unconfined process:

module phpfpm_mariadb_socket 1.0;

require {
        type httpd_t;
        type unconfined_service_t;
        class unix_stream_socket connectto;
}

#============= httpd_t ==============
allow httpd_t unconfined_service_t:unix_stream_socket connectto;

I see two obvious differences: Apache 2.4.37 vs 2.4.51 (and potential related SELinux policy changes which I couldn’t track down) and EL 8.6 vs EL 9 SELinux core changes (both had “latest” available updates applied). I copied the phpMyAdmin install from my 8.6 system into my 9 system, under the same usernames with the same permissions. I don’t think that the php-fpm user:group configuration is relevant to the process contexts, or is it?

3

Alright, here’s my latest update:
10.5 works
10.6 doesn’t
10.7 works
10.8 work
etc.

I was hoping to use 10.6 since it is the LTS release…clearly there is something wrong with it though. I’m on the MariaDB slack channel at the moment, but for now I’ll revert to 10.5 from the MariaDB repo, since that has support for 2 years-ish.

4

In my opinion, this is misleading and completely wrong.

An EL distro like AlmaLinux is supposed to run the EL variant of MariaDB that comes with it and those extra versions that come as module streams.

Anything else, is unsupported or just plain wrong and you depend on 3rd parties to help you fix all those incompatibility problems.

EL distros get their updates from RHEL and have all needed fixes backported.

5

Running 3rd party software on an open source Linux solution is completely wrong and misleading? Wow.

If it doesn’t interest one in a community forum, usually the best action is to keep scrolling.

6

What I’m worried about, is that some else may read the above post and think that EL has problems running MariaDB (which it doesn’t) or think that the proper way to run MariaDB is via a foreign package (which isn’t the proper way). Hence my warning above.

7

According to Red Hat Enterprise Linux Application Streams Life Cycle - Red Hat Customer Portal
RHEL 8 (and hence Alma 8) has currently two streams for MariaDB:

  • 10.3, supported by Red Hat to May 2029
  • 10.5, supported by Red Hat to May 2026

They are in base distro, in the appstream repo, and one needs the dnf module command to select/switch stream.
Red Hat could release newer MariaDB stream before Full Support phase of RHEL 8 is over.

Packages of base distro should work together “out of the box”. If not, then there is a bug (in RHEL).

The packages that are in base distro are maintained by Red Hat, including backports (of both features and security fixes). Therefore, version “Y” of package X in RHEL unavoidably differs from version Y that upstream X once had. For example, kernel-3.10.0-1160.80.1.el7 in RHEL 7 is very different from the 3.10.0 that Linux kernel developers released years ago. Upstream 3.10.0 has been dead years now; the RHEL “3.10.0” lives to June 2024 (June 2026 for ELS customers).

Third-party content may or may not work fine. Most of it does, most of the time. It is ok to use third-party content, particularly when base distro does not have something. Replacing something that base distro does have requires more consideration.

8

@jlehtone thank you for a thorough post. In my case I wanted to use a later version than EL provided for various reasons, but you’ve successfully address my support reasoning rendering my case for the mariadb repo moot. That was a nuance about EL that I didn’t understand. When I did my AL 9 install, I followed the steps I used for 8.5 including selinux and MariaDB from mariadb repo. I was surprised it didn’t work and that resulted in lots of digging and VM snapshot restores. I tried digging in to selinux specific changes in 9, but I didn’t get very far before I was in over my head. To be clear, selinux in permissive mode allows it to work so the policies need to be developed for the MariaDB repo software which of course, is not the responsibility of EL.

@sams_daughter Foreign? That sounds like an old Microsoft ad. Don’t use other browsers, use Internet Explorer instead since it ships with Windows. I understand the goal of your statements, but I think you’ve used words that are too extreme for the situation. I realize now that to do what I did, I should have waited for EL 9 instructions from MariaDB, as I’ve since realized how much changed in EL 9 that would make EL 8 instructions not work as written.