After installing the latest selinux-policy package MariaDB does not start as the rules for MariaDB are missing from the latest selinux-policy package. Reproducible: Always Steps to Reproduce: 1. Update the system to the selinux-policy package version 42.8.1 2. If the update is part of a bigger transaction, it will likely fail as other services will fail to start after upgrade Actual Results: All the entries for mariadb disappears. Example taken from a machine with 42.8.1 (only row is local customization): [localadmin@itmil01pzbp01 ~]$ sudo grep mariadb -r /var/lib/selinux/targeted/active /var/lib/selinux/targeted/active/file_contexts.local:/mariadb_datadir(/.*)? system_u:object_r:mysqld_db_t:s0 Example taken from a machine with 42.7.1 (latest row is local customization): [luca.cavana-csa.com@itmil01pzbs01 ~]$ sudo grep mariadb -r /var/lib/selinux/targeted/active /var/lib/selinux/targeted/active/file_contexts:/run/mariadb(/.*)? system_u:object_r:mysqld_var_run_t:s0 /var/lib/selinux/targeted/active/file_contexts:/var/log/mariadb(/.*)? system_u:object_r:mysqld_log_t:s0 /var/lib/selinux/targeted/active/file_contexts:/usr/lib/systemd/system/mariadb.* -- system_u:object_r:mysqld_unit_file_t:s0 /var/lib/selinux/targeted/active/file_contexts:/usr/bin/mariadbd -- system_u:object_r:mysqld_exec_t:s0 /var/lib/selinux/targeted/active/file_contexts:/usr/libexec/mariadbd -- system_u:object_r:mysqld_exec_t:s0 /var/lib/selinux/targeted/active/file_contexts:/usr/bin/mariadbd-safe -- system_u:object_r:mysqld_safe_exec_t:s0 /var/lib/selinux/targeted/active/file_contexts:/usr/bin/mariadb-backup -- system_u:object_r:mysqld_exec_t:s0 /var/lib/selinux/targeted/active/file_contexts:/usr/bin/mariadb-upgrade -- system_u:object_r:mysqld_exec_t:s0 /var/lib/selinux/targeted/active/file_contexts:/usr/bin/mariadbd-safe-helper -- system_u:object_r:mysqld_exec_t:s0 /var/lib/selinux/targeted/active/file_contexts.local:/mariadb_datadir(/.*)? system_u:object_r:mysqld_db_t:s0 Expected Results: MariaDB entries are kept. Additional Information: As a workaround set SELinux in permissive mode
I guess mariadb now needs Requires: (mysql-selinux if selinux-policy-%{selinuxtype}) https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing The module was removed as agreed in https://github.com/fedora-selinux/selinux-policy/pull/2785
The above does not completely fix it as when MariaDB now starts, permissions are incorrectly assigned to the unix domain socket: $ sudo systemctl start mariadb.service $ sudo ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_db_t:s0 0 Sep 16 14:55 /var/lib/mysql/mysql.sock $ sudo restorecon -Rv /var/lib/mysql/ Relabeled /var/lib/mysql/mysql.sock from system_u:object_r:mysqld_db_t:s0 to system_u:object_r:mysqld_var_run_t:s0 $ sudo ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_var_run_t:s0 0 Sep 16 14:55 /var/lib/mysql/mysql.sock
I'll take a look at it
Hi, can you please give us the output from your system of: # rpm -qa | grep -i -e maria -e mysql | sort ?
$ rpm -qa | grep -i -e maria -e mysql | sort MariaDB-client-11.4.7-1.fc40.x86_64 MariaDB-client-compat-11.4.7-1.fc40.noarch MariaDB-common-11.4.7-1.fc40.x86_64 MariaDB-server-11.4.7-1.fc40.x86_64 MariaDB-server-compat-11.4.7-1.fc40.noarch MariaDB-shared-11.4.7-1.fc40.x86_64 mysql-selinux-1.0.14-1.fc42.noarch zabbix-proxy-mysql-7.2.12-release1.el9.x86_64
Thanks, I see you have a mix of MariaDB *upstream* RPMs for F40, Fedora 'mysql-selinux' package for F42 and a RHEL 9 / EPEL 9 'zabbix-proxy-mysql' rpm. Can you please show us what your actual system is? # cat /etc/os-release
Hello, the system is a Fedora Server 42. $ cat /etc/os-release NAME="Fedora Linux" VERSION="42 (Server Edition)" RELEASE_TYPE=stable ID=fedora VERSION_ID=42 VERSION_CODENAME="" PLATFORM_ID="platform:f42" PRETTY_NAME="Fedora Linux 42 (Server Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:42" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f42/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=42 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=42 SUPPORT_END=2026-05-13 VARIANT="Server Edition" VARIANT_ID=server The system is an upgrade from a Fedora Server 40 and I had the old MariaDB repositories in /etc/yum.repos.d/ that I modified to the current ones for Fedora 42 and updated the packages so the current list is: $ rpm -qa | grep -i -e maria -e mysql | sort MariaDB-client-11.4.8-1.fc42.x86_64 MariaDB-client-compat-11.4.8-1.fc42.noarch MariaDB-common-11.4.8-1.fc42.x86_64 MariaDB-server-11.4.8-1.fc42.x86_64 MariaDB-server-compat-11.4.8-1.fc42.noarch MariaDB-shared-11.4.8-1.fc42.x86_64 mysql-selinux-1.0.14-1.fc42.noarch zabbix-proxy-mysql-7.2.12-release1.el9.x86_64
Hi, after having a look at the socket and its permissions I have concluded that it only affects upstream MariaDB packages. As for the main selinux issues, they should be solved by installing the `mysql-selinux` package and relabeling the necessary files using restorecon or any other selinux tool. I have reported this to upstream on their chat platform[0] and an issue will be created either by us or them. Unfortunately I cannot suggest a solution for the socket relabel at the moment other than adding: ``` [Service] ExecStartPost=restorecon -Rv /var/lib/mysql/ ``` to the mariadb service using `systemctl edit mariadb` and reloading the daemon using `systemctl daemon-reload`. This will fix the permissions for the socket on the restart of the service but requires editing the service yourself. [0]https://mariadb.zulipchat.com/#narrow/channel/118759-general/topic/.E2.9C.94.20MDEV-30520.20selinux.20compatible.20with.20MariaDB.20released.20pac.2E.2E.2E/with/540029333
For the socket I will open a bug upstream as the SELinux label contrast to their documentation; anyway it does not look to be the problem why services which were allowed before, now are not. By using audit2allow I've been able to allow the local application (Zabbix) to connect and write to the socket and configure SELinux back in Enforcing state. I'm pretty sure before it was not the case and something was indeed modified when mysql-related rules were moved from the selinux-policy into the mysql-selinux package. I think that this change should have been handled with a proper change request with the release of Fedora 43. Nobody expects that a regular update will make major adjustments like this. Sysadmins tend to read changes on version upgrades and can adjust their systems accordingly.
(In reply to Pavol Sloboda from comment #8) > Hi, after having a look at the socket and its permissions I have concluded > that it only affects upstream MariaDB packages. As for the main selinux > issues, they should be solved by installing the `mysql-selinux` package and > relabeling the necessary files using restorecon or any other selinux tool. Context restoring should actually be handled in mysql-selinux post script, as long as these directives are used %selinux_relabel_pre -s %{selinuxtype} ... %selinux_relabel_post -s %{selinuxtype} It does not apply to filesystems like /run and may also not help with open files, both of it should be resolved by reboot. I now also see the Requires field is there (I did not see it before): # rpm -q --requires mariadb-server | grep mysql-selinux (mysql-selinux >= 1.0.10 if selinux-policy-targeted)
@Luca can you please test this: sudo wget https://ci.mariadb.org/59717/amd64-fedora-42-rpm-autobake/MariaDB.repo -O /etc/yum.repos.d/MariaDB.repo This is the MariaDB-11.4 that is in its last week or so before a release (from our CI environment, its not a permanent link), + Pavol's recommended change https://github.com/MariaDB/server/commit/f2826dff276c681d881a91c7a3766bdf371cbb1b. It installed and after the service started for me seems ok with even the socket still on the right label so some more testing needs to see what causes that difference: I have a config file directive changing the location to /var/lib/mysql/mysql.sock to see how its processed. $ sudo systemctl status mariadb.service ● mariadb.service - MariaDB 10.11.15 database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; preset: disabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf /etc/systemd/system/mariadb.service.d └─migrated-from-my.cnf-settings.conf, override.conf Active: active (running) since Fri 2025-09-19 14:56:57 AEST; 4s ago Invocation: b6a3b3689f3949789a87555445b2184b Docs: man:mariadbd(8) https://mariadb.com/kb/en/library/systemd/ Process: 900571 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Process: 900572 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || ex> Process: 900614 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Main PID: 900602 (mariadbd) Status: "Taking your SQL requests now..." Tasks: 10 (limit: 250169) Memory: 4.4G (peak: 4.4G) CPU: 791ms CGroup: /system.slice/mariadb.service └─900602 /usr/sbin/mariadbd Sep 19 14:56:56 bark mariadbd[900602]: 2025-09-19 14:56:56 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. Sep 19 14:56:56 bark mariadbd[900602]: 2025-09-19 14:56:56 0 [Note] InnoDB: log sequence number 10824995612; transaction id 272 Sep 19 14:56:56 bark mariadbd[900602]: 2025-09-19 14:56:56 0 [Note] Plugin 'FEEDBACK' is disabled. Sep 19 14:56:56 bark mariadbd[900602]: 2025-09-19 14:56:56 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool Sep 19 14:56:56 bark mariadbd[900602]: 2025-09-19 14:56:56 0 [Note] InnoDB: Buffer pool(s) load completed at 250919 14:56:56 Sep 19 14:56:57 bark mariadbd[900602]: 2025-09-19 14:56:57 0 [Note] Server socket created on IP: '0.0.0.0', port: '3306'. Sep 19 14:56:57 bark mariadbd[900602]: 2025-09-19 14:56:57 0 [Note] Server socket created on IP: '::', port: '3306'. Sep 19 14:56:57 bark mariadbd[900602]: 2025-09-19 14:56:57 0 [Note] /usr/sbin/mariadbd: ready for connections. Sep 19 14:56:57 bark mariadbd[900602]: Version: '10.11.15-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server Sep 19 14:56:57 bark systemd[1]: Started mariadb.service - MariaDB 10.11.15 database server. $ ls -laZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_var_run_t:s0 0 Sep 19 14:56 /var/lib/mysql/mysql.sock
Created attachment 2106992 [details] upgrade MariaDB with MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest
@Daniel, I have been able to test the build provided and it seems to fix everything from package dependencies to the wrong permission on the unix socket. I tested the following scenarios: - An upgrade from selinux-policy 42.7-1.fc42 (where MySQL/MariaDB SELinux rules were still there) - An upgrade from selinux-policy 42.8-1.fc42 (where MySQL/MariaDB SELinux rules were removed but dependency for mysql-selinux not yet created) In the recent attachment I uploaded you can find the upgrade procedure for the first scenario. On the system that originated this issue I was able to remove the custom policy I had to made with autdit2allow to have Zabbix be able to bind/write to the unix socket. Everything seems to be working as originally intended. So now it should just be a matter of waiting for the patch to get the next release cycle, right? Thank you very much, Luca
Thank you for the testing. Yes it will just appear in the next release cycle, notionally 2025-10-23.
Updating to selinux-policy 42.13 from 42.12 breaks the socket again. @itmil01pzbp01 ~]$ sudo dnf list --installed | grep -E -i '(^selinux)|mariadb|(^mysql)' MariaDB-client.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-client-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-common.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-shared.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest galera-4.x86_64 26.4.23-1.fc42 mariadb mysql-selinux.noarch 1.0.14-1.fc42 updates selinux-policy.noarch 42.13-1.fc42 updates selinux-policy-targeted.noarch 42.13-1.fc42 updates @itmil01pzbs01 ~]$ sudo dnf list --installed | grep -E -i '(^selinux)|mariadb|(^mysql)' MariaDB-client.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-client-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-common.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-shared.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest galera-4.x86_64 26.4.23-1.fc42 mariadb mysql-selinux.noarch 1.0.14-1.fc42 updates selinux-policy.noarch 42.12-1.fc42 updates selinux-policy-targeted.noarch 42.12-1.fc42 updates I had to create the following policy to have it working by using audit2allow as a temporary workaround. module my-zabbixproxy 1.0; require { type unlabeled_t; type zabbix_t; type unconfined_service_t; type mysqld_db_t; class dir search; class sock_file write; class unix_stream_socket connectto; } #============= zabbix_t ============== allow zabbix_t mysqld_db_t:sock_file write; allow zabbix_t unconfined_service_t:unix_stream_socket connectto; allow zabbix_t unlabeled_t:dir search; allow zabbix_t unlabeled_t:sock_file write; The release notes from 42.13 don't specify any changes related to mysql but if you take a look and compare "sudo grep mysql -r /var/lib/selinux/targeted/active" between the two systems there are some differences, so something was touched indeed.
The mysql-selinux-1.0.14 package should have https://github.com/devexp-db/mysql-selinux/blob/master/mysql.fc#L54, meaning the /var/lib/mysql/mysql.sock would get a mysqld_var_run_t type label. Then the zabbix rule: https://src.fedoraproject.org/rpms/zabbix/blob/f42/f/zabbix.te#_185 Should facilitate connection via macro: https://github.com/devexp-db/mysql-selinux/blob/7f0e451a978ee6a762ff971e92da400a0e3131af/mysql.if#L107-L115 Could it be previous comment 10 that the relabel /var/lib/mysql/mysql.sock by mysql-selinux-1.0.14 isn't occur on open files?
Hi, I would advise against adding the rule you have described above as it is way too permissive and allows zabbix to connect and write to just about any socket and to search just about any directory that is not labeled, the switch of the selinux-policy versions might have broken something during the installation. Could you please try restarting your system to see if it fixes these issues? I totally agree with Daniel that they should get resolved by themselves as the rules already do exist. What I believe happened is that since you didn't have mysql-selinux installed before the socket was wrongly labeled and since selinux does not relabel open files (as mentioned above) it didn't get fixed. This should not occur under any other circumstance and is an aftereffect of the change we made in this issue.
Hello Pavol, this is the situation of the socket file after rebooting the system. $ sudo ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_db_t:s0 0 Nov 6 11:26 /var/lib/mysql/mysql.sock $ sudo dnf list --installed | grep -E -i '(^selinux)|mariadb|(^mysql)' MariaDB-client.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-client-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-common.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-shared.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest galera-4.x86_64 26.4.23-1.fc42 mariadb mysql-selinux.noarch 1.0.14-1.fc42 updates selinux-policy.noarch 42.13-1.fc42 updates selinux-policy-targeted.noarch 42.13-1.fc42 updates If I stop and restart mariadb the socket file gets deleted and then recreated with the same label applied.
Hi, That seems good, any operation with the socket should be fine as long as you have the fix provided by Daniel or a version of the package which the fix will make it to. If you find any other issues feel free to reach out to us.
Hello Pavol, it doesn't work. It should be mysqld_var_run as https://github.com/devexp-db/mysql-selinux/blob/master/mysql.fc#L54 but instead it is mysqld_db_t. Before the update to selinux-policy.noarch 42.13-1.fc42 (i.e. 42.12-1.fc42) it was working correctly with the fix provided by Daniel (which I'm running, and the socket was labeled correctly as mysqld_var_run). After the upgrade to selinux-policy.noarch 42.13-1.fc42 it stopped working and the socket is now labeled as mysqld_db_t.
I will look into this deeper and notify Daniel. For now I have a quick and easy fix: use `systemctl edit mariadb` and add this to the service: ``` [Service] ExecStartPost=/usr/bin/restorecon /var/lib/mysql/mysql.sock ``` afterwards run `systemctl daemon-reload` and `systemctl restart mariadb` this will produce the expected labels for the socket: srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_var_run_t:s0 0 Nov 10 10:31 mysql.sock Why this does not happen with the upstream rpms by itself but it does with ours is still beyond my understanding at the moment. I will investigate deeper.
Hello Pavol, thank you; from my experience it's the behavior that it's not consistent. Both systems have the same set of packages installed but they label the socket in different ways. This is an example from the "correctly behaving" (post Daniel fix) system: $ sudo dnf list --installed | grep -E -i '(^selinux)|mariadb|(^mysql)' MariaDB-client.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-client-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-common.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-shared.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest galera-4.x86_64 26.4.23-1.fc42 mariadb mysql-selinux.noarch 1.0.14-1.fc42 updates selinux-policy.noarch 42.14-1.fc42 updates selinux-policy-targeted.noarch 42.14-1.fc42 updates $ sudo ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_var_run_t:s0 0 Nov 7 16:31 /var/lib/mysql/mysql.sock This is another system with the exact same sequence of packages installed, but with a wrongly labeled socket: $ sudo dnf list --installed | grep -E -i '(^selinux)|mariadb|(^mysql)' MariaDB-client.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-client-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-common.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-server-compat.noarch 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest MariaDB-shared.x86_64 11.4.9-1.fc42 MariaDB-bb-11.4-MDEV-37680-danblack-pkgtest galera-4.x86_64 26.4.24-1.fc42 mariadb mysql-selinux.noarch 1.0.14-1.fc42 updates selinux-policy.noarch 42.14-1.fc42 updates selinux-policy-targeted.noarch 42.14-1.fc42 updates $ sudo ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_db_t:s0 0 Nov 10 17:10 /var/lib/mysql/mysql.sock <<<<<<<<----------- wrong SELinux label here $ sudo restorecon -Rv /var/lib/mysql/mysql.sock Relabeled /var/lib/mysql/mysql.sock from system_u:object_r:mysqld_db_t:s0 to system_u:object_r:mysqld_var_run_t:s0 $ sudo systemctl restart mariadb.service <<<<<<<<----------- no workaround/modifications to systemd service unit applied here, bare stock. $ sudo ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_db_t:s0 0 Nov 10 17:13 /var/lib/mysql/mysql.sock
As additional context, even with the correct SELinux applied by restorecon; the service cannot connect to the socket. $ ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_var_run_t:s0 0 Nov 10 17:13 /var/lib/mysql/mysql.sock Nov 10 17:34:40 itmil01pzbp01 audit[56745]: AVC avc: denied { connectto } for pid=56745 comm="zabbix_proxy" path="/var/lib/mysql/mysql.sock" scontext=system_u:system_r:zabbix_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
Can you find the service zabbix tries to connect to? ps -eo pid,fname,cmd,context | grep -e CONTEXT -e unconfined_service_t
On the system with the wrongly configured socket, it's MariaDB that runs as an unconfined service: $ ps -eo pid,fname,cmd,context | grep -e CONTEXT -e unconfined_service_t PID COMMAND CMD CONTEXT 856 zabbix_a /usr/sbin/zabbix_agent2 -c system_u:system_r:unconfined_service_t:s0 56139 mariadbd /usr/sbin/mariadbd system_u:system_r:unconfined_service_t:s0 On the system where the socket is labeled correctly, MariaDB runs with it's own context: $ ps -eo pid,fname,cmd,context | grep -e CONTEXT -e unconfined_service_t -e maria PID COMMAND CMD CONTEXT 879 zabbix_a /usr/sbin/zabbix_agent2 -c system_u:system_r:unconfined_service_t:s0 946 mariadbd /usr/sbin/mariadbd system_u:system_r:mysqld_t:s0
I don't know what fixed it on the system that was (still) wrongly configured even after Daniel's patch; but, in the last maintenance window the MariaDB on the server started performing again as expected . I've just made the system current with the last MariaDB 11.4.9-1: Packages altered: Action Package Reason Repository Reinstall MariaDB-client-0:11.4.9-1.fc42.x86_64 User mariadb Reinstall MariaDB-client-compat-0:11.4.9-1.fc42.noarch Weak Dependency mariadb Reinstall MariaDB-common-0:11.4.9-1.fc42.x86_64 Dependency mariadb Reinstall MariaDB-server-0:11.4.9-1.fc42.x86_64 User mariadb Reinstall MariaDB-server-compat-0:11.4.9-1.fc42.noarch Weak Dependency mariadb Reinstall MariaDB-shared-0:11.4.9-1.fc42.x86_64 Dependency mariadb Replaced MariaDB-client-0:11.4.9-1.fc42.x86_64 User @System Replaced MariaDB-client-compat-0:11.4.9-1.fc42.noarch Weak Dependency @System Replaced MariaDB-common-0:11.4.9-1.fc42.x86_64 Dependency @System Replaced MariaDB-server-0:11.4.9-1.fc42.x86_64 User @System Replaced MariaDB-server-compat-0:11.4.9-1.fc42.noarch Weak Dependency @System Replaced MariaDB-shared-0:11.4.9-1.fc42.x86_64 Dependency @System Then I upgraded the system, and in the stream of packages I have : Upgrade selinux-policy-0:42.17-1.fc42.noarch Dependency updates Upgrade selinux-policy-targeted-0:42.17-1.fc42.noarch Group updates Upgrade zabbix-agent2-0:7.4.5-release2.el9.x86_64 User zabbix Upgrade zabbix-proxy-mysql-0:7.4.5-release2.el9.x86_64 User zabbix Upgrade zabbix-selinux-policy-0:7.4.5-release2.el9.x86_64 User zabbix Upgrade zabbix-sql-scripts-0:7.4.5-release2.el9.noarch User zabbix Replaced selinux-policy-0:42.14-1.fc42.noarch Dependency @System Replaced selinux-policy-targeted-0:42.14-1.fc42.noarch Group @System Replaced zabbix-agent2-0:7.2.14-release1.el9.x86_64 User @System Replaced zabbix-proxy-mysql-0:7.2.14-release1.el9.x86_64 User @System Replaced zabbix-selinux-policy-0:7.2.14-release1.el9.x86_64 User @System Replaced zabbix-sql-scripts-0:7.2.14-release1.el9.noarch User @System After which: $ ls -lahZ /var/lib/mysql/mysql.sock srwxrwxrwx. 1 mysql mysql system_u:object_r:mysqld_var_run_t:s0 0 Dec 2 20:38 /var/lib/mysql/mysql.sock $ ps -eo pid,fname,cmd,context | grep -e CONTEXT -e unconfined_service_t -e maria PID COMMAND CMD CONTEXT 850 zabbix_a /usr/sbin/zabbix_agent2 -c system_u:system_r:unconfined_service_t:s0 895 mariadbd /usr/sbin/mariadbd system_u:system_r:mysqld_t:s0 Thank you to everyone involved.
Thanks for letting us know. I'm glad it works as expected now