Red Hat Bugzilla – Bug 1477575
service start fails due to wrong selinux type of logfile
Last modified: 2017-09-21 03:42:41 EDT
Description of problem:
After database initialisation, mysqld.log has wrong type.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rm -rf /var/opt/rh/rh-mysql56/lib/mysql/*
2. rm /var/opt/rh/rh-mysql56/log/mysql/mysqld.log
3. service rh-mysql56-mysqld restart
4. ls -lZ /var/opt/rh/rh-mysql56/log/mysql/mysqld.log
-rw-rw----. mysql mysql system_u:object_r:var_log_t:s0 /var/opt/rh/rh-mysql56/log/mysql/mysqld.log
-rw-r-----. mysql mysql system_u:object_r:mysqld_log_t:s0 /var/opt/rh/rh-mysql56/log/mysql/mysqld.log
probably, this comes from 'install' usage (instead of older 'touch') within prepare script
BTW, note also the writability by group while it should be just group readable
also, I'm a bit lost in the code paths, because if you keep the database directory and remove just the logfile, on next server start the logfile gets recreated with proper attributes, so probably the whole logfile creation during database directory initialisation could be left out ...
Created attachment 1308674 [details]
proposed patch with restorecon call
(In reply to Karel Volný from comment #0)
> Additional info:
> probably, this comes from 'install' usage (instead of older 'touch') within
> prepare script
The install section is not used, it should only be triggered when someone puts the log file into /var/log. The log file is created by /opt/rh/rh-mysql56/root/usr/bin/mysql_install_db, which does not fix content properly (does not have mysql SELinux context as mysqld has).
> BTW, note also the writability by group while it should be just group
> also, I'm a bit lost in the code paths, because if you keep the database
> directory and remove just the logfile, on next server start the logfile gets
> recreated with proper attributes, so probably the whole logfile creation
> during database directory initialisation could be left out ...
The log file is re-created with correct attributes, because this time the log file is created by mysqld daemon itself, which runs with proper SELinux context. So the issue you see is only visible when the log file is created by mysql_install_db (which is run only when the database directory is empty).
So, I think the correct fix is to run restorecon on the log file directly after mysql_install_db call. Proposed patch attached.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.