Latest MariaDB installs mysql-selinux and breaks galera sync

Rocky Linux Help & Support
1

Hi all,

Just a heads up in case any of you are using the following combo the latest updates from upstream and MariaDB break Galera replication setups

  • RL9
  • MariaDB 11.4.9 from MariaDB repository
  • Galera DB cluster replication
  • SELinux enabled and enforcing

Background

Part of the updates released overnight included MariaDB 11.4.9, upgraded from 11.4.8 both direct from the MariaDB rpm repos. New version of MariaDB now has dependencies for mysql-selinux (installs version 1.0.14) and many other selinux packages that weren’t required previously with MariaDB 11.4.8

Dependencies resolved.

Package                                                   Architecture                        Version                                          Repository                              Size

Upgrading:
MariaDB-client                                            x86_64                              11.4.9-1.el9                                     mariadb                                9.4 M
MariaDB-client-compat                                     noarch                              11.4.9-1.el9                                     mariadb                                 11 k
MariaDB-common                                            x86_64                              11.4.9-1.el9                                     mariadb                                 89 k
MariaDB-server                                            x86_64                              11.4.9-1.el9                                     mariadb                                 19 M
MariaDB-server-compat                                     noarch                              11.4.9-1.el9                                     mariadb                                9.0 k
MariaDB-shared                                            x86_64                              11.4.9-1.el9                                     mariadb                                130 k
Installing dependencies:
checkpolicy                                               x86_64                              3.6-1.el9                                        appstream                              352 k
mysql-selinux                                             noarch                              1.0.14-1.el9_6                                   appstream                               36 k
policycoreutils-python-utils                              noarch                              3.6-2.1.el9                                      appstream                               71 k
python3-audit                                             x86_64                              3.1.5-4.el9                                      appstream                               83 k
python3-distro                                            noarch                              1.5.0-7.el9                                      appstream                               36 k
python3-libsemanage                                       x86_64                              3.6-5.el9_6                                      appstream                               78 k
python3-policycoreutils                                   noarch                              3.6-2.1.el9                                      appstream                              2.0 M
python3-setools                                           x86_64                              4.4.4-1.el9                                      baseos                                 551 k
python3-setuptools                                        noarch                              53.0.0-13.el9_6.1                                baseos                                 837 k

Transaction Summary

Install  9 Packages
Upgrade  6 Packages

Problem

After running dnf update, the update hangs at “Running scriptlet: MariaDB-server-11.4.9-1.el9.x86_64”, digging into the stuck part, it is the restart of MariaDB and this is reported in the log:

Nov 07 09:41:57 ``dbnode2.etisoftware.co.uk`` mariadbd[50960]: WSREP_SST: [INFO] rsync SST started on joiner (20251107 09:41:57.596)
Nov 07 09:41:57 ``dbnode2.etisoftware.co.uk`` mariadbd[50960]: WSREP_SST: [INFO] /proc/net/tcp{,6} is being used directly to avoid excessive selinux AVC notices (20251107 09:41:57.667)
Nov 07 09:41:57 ``dbnode2.etisoftware.co.uk`` rsyncd[51087]: rsyncd version 3.2.5 starting, listening on port 4444
Nov 07 09:41:57 ``dbnode2.etisoftware.co.uk`` rsyncd[51087]: bind() failed: Permission denied (address-family 2)
Nov 07 09:41:57 ``dbnode2.etisoftware.co.uk`` rsyncd[51087]: unable to bind any inbound sockets on port 4444
Nov 07 09:41:57 ``dbnode2.etisoftware.co.uk`` rsyncd[51087]: rsync error: error in socket IO (code 10) at socket.c(545) [Receiver=3.2.5]
Nov 07 09:42:00 ``dbnode2.etisoftware.co.uk`` mariadbd[50951]: 2025-11-07 9:42:00 0 [Note] WSREP: (fff16b24-9847, ‘tcp://0.0.0.0:4567’) turning message relay requesting off

Steps to fix

Killing the wsrep_sst_rsync process allows the MariaDB service to complete the restart and the dnf process to complete. We find these errors in the selinux AVC logs:

0 10:10:24 root@dbnode2 ~ $ audit2why -a
type=AVC msg=audit(1762508517.711:2864): avc: denied { name_bind } for pid=51087 comm=“rsync” src=4444 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:kerberos_port_t:s0 tclass=tcp_socket permissive=0
Was caused by:
The boolean nis_enabled was set incorrectly.
Description:
Allow nis to enabled

    Allow access by executing:
    # setsebool -P nis_enabled 1

type=AVC msg=audit(1762508986.110:2891): avc: denied { name_bind } for pid=59722 comm=“rsync” src=4444 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:kerberos_port_t:s0 tclass=tcp_socket permissive=1
Was caused by:
The boolean nis_enabled was set incorrectly.
Description:
Allow nis to enabled

    Allow access by executing:
    # setsebool -P nis_enabled 1

type=AVC msg=audit(1762508986.113:2892): avc: denied { name_bind } for pid=58523 comm=“mariadbd” src=4568 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=1
Was caused by:
The boolean nis_enabled was set incorrectly.
Description:
Allow nis to enabled

    Allow access by executing:
    # setsebool -P nis_enabled 1

type=AVC msg=audit(1762508989.077:2894): avc: denied { name_connect } for pid=58523 comm=“mariadbd” dest=4568 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=1
Was caused by:
One of the following booleans was set incorrectly.
Description:
Allow nis to enabled

    Allow access by executing:
    # setsebool -P nis_enabled 1
    Description:
    Allow mysql to connect any

    Allow access by executing:
    # setsebool -P mysql_connect_any 1

Changing the selinux bool settings as reported allows the service to restart and sync normally, as does switching selinux to permissive mode with setenforce 0.

When running MariaDB 11.4.8 both of the above boolean values are set to off, there is no mysql-selinux package installed as a dependency and all sync options work normally.

2

Well I would say that is normal behaviour when selinux is enabled. If it worked previously and stopped, that is because they now provided the selinux related items to help secure it. The defaults are always that booleans are disabled. Therefore, if you install something that needs booleans configured, then you need to configure them - which is what you found out.

It’s no different from installing Apache, and then deciding to change it from running on port 80 to running on port 8080 - if you don’t configure the booleans to allow that, then the service won’t start. It’s the same also if you want Apache websites to talk with a database, then you need to enable booleans for that as well. They are disabled by default for a reason - security. So therefore you only enable if you need them.

The majority of people that will install mysql/mariadb perhaps don’t have a cluster, and therefore those options aren’t enabled by default when mariadb is installed - you have to configure that yourself manually. Thus, if it is configured additionally than the usual default, then it requires the booleans to be set.

MariaDB should have warned about that though in their information - since it’s their repository and their changes that they made.

3

Rocky Linux 9 does offer MariaDB 10.5 and 10.11. Does the “majority of people” even resort to third-party repo to get MariaDB, or are they content with what Rocky has?

If the MariaDB and galera from Rocky do also require manual updates to SELinux config and if Rocky’s docs do not mention that, then there is an action point for Rocky.

4

Well no not really. There is no action point for Rocky either. I’ll give a perfect example which I’ve already hinted at.

First, I install Apache httpd package, and it is running. Let’s say I now install PHP and that is also working fine. Now I want my PHP application, let’s say a CMS like Joomla or whatever, which requires a MariaDB database. The database is configured and running, but Apache cannot connect to it. I can look at getsebool, and I have options like httpd_can_network_connect, or httpd_can_connect_db (or whatever they are exactly). Neither of these are enabled by default, and as such my application violates selinux policies. Using the tools will tell me that I need to enable one of those sebooleans.

There is no difference here for MariaDB. A basic installation with Rocky packages works fine. However, if we were then to configure a cluster, I would need to manually enable the sebooleans just like I did with Apache. Had I enabled that previously, and then upgraded the Rocky packages, then they still work fine.

I think the problem here is that the MariaDB Community repo was used, and there was no selinux packages previously, and thus no selinux policies were applied. Then package updates were made, which then broke it, because selinux is now enabled for it, and the required booleans or selinux policies were being violated. The package update isn’t going to know about that. Sure, we could argue that they could post_install script it to check if cluster enabled, then enable these policies. But to enable them by default wouldn’t be a good idea since you can choose how restrictive you want to be with the policies.

Note, Apache can use httpd_can_connect_any which means it allows everything. Now that wouldn’t be good as it would enable all protocols. Maybe we only want Apache to talk with the DB, but we don’t necessarily want to allow it to talk to LDAP or whatever else.

We could also say that for example I’m using MariaDB without selinux (disabled), and I have it configured as a cluster, but then decide myself to enable selinux. I would have to make sure to autorelabel for a start, but that might not be enough to deal with the cluster settings of MariaDB. I would most likely have to manually enable the sebooleans - which is in essence almost the same situation as using the community repo, have a package install, and then find the minimum selinux configs are not enough for a full blown cluster. The packages aren’t that clever to try and figure out every single config possibility to apply the relevant booleans.

1 Like
5

Hmm, yes, I posted this really as a warning to others using Galera replication with SELinux, not as a finger pointing exercise at any group in-particular.

I’ve been tentatively patching various dev and test systems here and with various mixes of RHEL8/9, Rocky 8/9 and MariaDB 10.11.x/11.4.x/11.8.x and the only breaking upgrades at the minute are Galera clusters using port 4444 rsync wsrep replication - a normal single server MariaDB instance works fine.

I couldn’t at this point say if a RHEL/Rocky released MariaDB package running a cluster would be ok or also affected. I think the real issue has been triggered by the dependency to the new mysql-selinux package being added to EL9, and I suspect that hasn’t been fully tested with Galera clusters.

If somebody out there has a native RL MariaDB cluster to test on EL9 that would probably put it to bed.

N.B. There isn’t a mysql-selinux package dependency enforced on EL8 at all, regardless of MDB version or source.

What I would say is that if adding a forced dependency to a package from an external repository that breaks it part way through a OS version is what has happened, it is a) unexpected and b) an unwanted change. When it’s been fully tested against your own rpms that’s one thing, forcing it on untested external rpms that were already installed and working fine is completely different.

M

1 Like