Troubleshooting SELinux typically involves placing SELinux into permissive mode, rerunning problematic operations, checking for access denial messages in the SELinux audit log, and placing SELinux back into enforcing mode after problems are resolved.
To avoid placing the entire system into permissive mode using
setenforce, you can permit only the MySQL
service to run permissively by placing its SELinux domain
(mysqld_t
) into permissive mode using the
semanage command:
semanage permissive -a mysqld_t
When you are finished troubleshooting, use this command to place
the mysqld_t
domain back into enforcing mode:
semanage permissive -d mysqld_t
SELinux writes logs for denied operations to
/var/log/audit/audit.log
. You can check for
denials by searching for “denied” messages.
grep "denied" /var/log/audit/audit.log
The following sections describes a few common areas where SELinux-related issues may be encountered.
If a MySQL directory or file has an incorrect SELinux context, access may be denied. This issue can occur if MySQL is configured to read from or write to a non-default directory or file. For example, if you configure MySQL to use a non-default data directory, the directory may not have the expected SELinux context.
Attempting to start the MySQL service on a non-default data directory with an invalid SELinux context causes the following startup failure.
$> systemctl start mysql.service
Job for mysqld.service failed because the control process exited with error code.
See "systemctl status mysqld.service" and "journalctl -xe" for details.
In this case, a “denial” message is logged to
/var/log/audit/audit.log
:
$> grep "denied" /var/log/audit/audit.log
type=AVC msg=audit(1587133719.786:194): avc: denied { write } for pid=7133 comm="mysqld"
name="mysql" dev="dm-0" ino=51347078 scontext=system_u:system_r:mysqld_t:s0
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0
For information about setting the proper SELinux context for MySQL directories and files, see Section 8.7.4, “SELinux File Context”.
SELinux expects services such as MySQL Server to use specific ports. Changing ports without updating the SELinux policies may cause a service failure.
The mysqld_port_t
port type defines the ports
that the MySQL listens on. If you configure the MySQL Server to
use a non-default port, such as port 3307, and do not update the
policy to reflect the change, the MySQL service fails to start:
$> systemctl start mysqld.service
Job for mysqld.service failed because the control process exited with error code.
See "systemctl status mysqld.service" and "journalctl -xe" for details.
In this case, a denial message is logged to
/var/log/audit/audit.log
:
$> grep "denied" /var/log/audit/audit.log
type=AVC msg=audit(1587134375.845:198): avc: denied { name_bind } for pid=7340
comm="mysqld" src=3307 scontext=system_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0
For information about setting the proper SELinux port context for MySQL, see Section 8.7.5, “SELinux TCP Port Context”. Similar port access issues can occur when enabling MySQL features that use ports that are not defined with the required context. For more information, see Section 8.7.5.2, “Setting the TCP Port Context for MySQL Features”.
SELinux may not be aware of application changes. For example, a new release, an application extension, or a new feature may access system resources in a way that is not permitted by SELinux, resulting in access denials. In such cases, you can use the audit2allow utility to create custom policies to permit access where it is required. The typical method for creating custom policies is to change the SELinux mode to permissive, identify access denial messages in the SELinux audit log, and use the audit2allow utility to create custom policies to permit access.
For information about using the audit2allow utility, refer to your distribution's SELinux documentation.
If you encounter access issues for MySQL that you believe should be handled by standard MySQL SELinux policy modules, please open a bug report in your distribution's bug tracking system.