Issue MariaDB upgrade clash with SELinux

[OElemental]

Server operating system version

AlmaLinux 9.8

Plesk version and microupdate number

Plesk Obsidian 18.0.79

Starting the upgrade process on MariaDB 11.4.12 I get this warning:
"The following MariaDB files have incorrect SELinux contexts configured: /usr/sbin/mariadbd (no SELinux context defined). The upgrade may cause websites to break because of incorrect SELinux contexts. To proceed, remove any custom SELinux modules that override MariaDB contexts and reinstall the 'mysql-selinux' package. Additionally, make sure there are no custom SELinux policies applied to the listed files."

I've seen several prior threads that suggest this clash should now be fixed. I'm now unclear what I should do. Can anyone advise next steps?

Thanks.

 

[scsa20]

If you want my honest opinion I think SELinux is not worth having enabled unless you have specific reasons for having it enabled because it tends to have more issues with services such as Plesk because of the need to set policies and what not to ensure proper operations. Personally I usually have it off. If you don't have any specific use case for using SELinux, I'd suggest that you turn it off.

If you must keep it enabled, then you'll want to double check and make sure you don't have any custom modules installed overwriting mariadb, reinstall the mariadb contexts, and restored context.

Since I'm lazy, I asked grok and claude and they gave close to the same steps, feel free to follow whichever one you want but before you follow the steps to fix SELinux's policies, make sure you have a snapshot you can restore to in case something goes arise.

https://grok.com/share/c2hhcmQtMw_aa8b6abd-b2cc-4410-9e74-844f48b58df4

Claude

Shared via Claude, an AI assistant from Anthropic

claude.ai

 

[Sebahat.hadzhi]

Hi, @OElemental . This warning was recently added by our team to prevent further issues after MariaDB upgrades on Almalinux. Typically, this is cause by wrong context set for for /usr/bin/mariadbd /previous pre-existing SELinux policy issues. It's best to hold off the upgrade until the issue is fixed. What you can try is re-installing the mysql-selinux policy as the error itself suggests. If that doesn't help, you need to check the actual contexts.

 

[OElemental]

Thanks both. Michael, before posting I asked the same of Claude and got a similar answer. And I thought this is too involved for my setup (SELinux is running as permissive and there are no log entries). So I disabled like you suggest.

Sebahat, for everyone's interest, if SELinux is in permissive mode then surely there should be no denial during upgrade? Is that right? If so, surely the warning should only appear when in enforcing mode?

 

[Sebahat.hadzhi]

@OElemental , no not necessarily. The check is performed even if SELinux is in permissive mode. You'll still get the warning if something is wrong with the context regardless of the mode. It is only skipped when SELinux is disabled or not installed at all. Here is the list of files being check with expected contexts:

["/usr/bin/mariadbd"]="system_u:object_r:mysqld_exec_t:s0"
["/usr/libexec/mariadbd"]="system_u:object_r:mysqld_exec_t:s0"
["/usr/sbin/mariadbd"]="system_u:object_r:mysqld_exec_t:s0"
["/var/lib/mysql/mysql.sock"]="system_u:object_r:mysqld_var_run_t:s0"

 

[OElemental]

Thanks @Sebahat.hadzhi but my point was slightly different. Fixing SELinux if you're not familiar with it is challenging and offputting. The problem with the 'warning' message appearing when in permissive mode is that it blocks the automated upgrade. Three ways round this:
1) Add a note to the warning to tell the user to temporarily put SELinux in disabled mode for the duration of the upgrade, or
1) Make it a true warning/advisory which the user can safely ignore and allow the upgrade to proceed, or
2) Keep the auto-upgrade mechanic as is, but only show the warning when SELinux is in enforcing mode (the only time something might break)

(I'm no expert so one of these might be a bad idea)

 

[scsa20]

1) Add a note to the warning to tell the user to temporarily put SELinux in disabled mode for the duration of the upgrade, or

This won't fix the underline issue. Sure, the person can disable SELinux, do the upgrade, then re-enabled it but doing so can cause things to not work properly until the rules is still fixed regardless.

1) Make it a true warning/advisory which the user can safely ignore and allow the upgrade to proceed, or

Same issue above, just because it's in permissive mode doesn't mean it won't cause issue. Sure, SELinux won't do anything but you will be getting a lot of unauthorized file access warnings in the audit log. The whole point of using permissive is to see what you are currently running on your server that you would need to create a policy for so when you do switch to enforcing those that triggered an authorized file access recorded in the audit log is already taken care of. It is not meant to be enabled for the life time of the server. This is also the reason why the checks still happens and blocks it even if it's in permissive mode.

2) Keep the auto-upgrade mechanic as is, but only show the warning when SELinux is in enforcing mode (the only time something might break)

No, for the reason I've already stated above.

(I'm no expert so one of these might be a bad idea)

Yes, those were bad ideas.

Long story short, if you had SELinux in permissive mode since you've first deployed it and it's been months, my suggestion is to just disable it as it's clear you're not needing it.