Description of problem: After database initialisation, mysqld.log has wrong type. Version-Release number of selected component (if applicable): rh-mysql56-mysql-server-5.6.37-1.el7.x86_64 How reproducible: always 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 Actual results: -rw-rw----. mysql mysql system_u:object_r:var_log_t:s0 /var/opt/rh/rh-mysql56/log/mysql/mysqld.log Expected results: -rw-r-----. mysql mysql system_u:object_r:mysqld_log_t:s0 /var/opt/rh/rh-mysql56/log/mysql/mysqld.log Additional info: 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 > 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 ... 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. https://access.redhat.com/errata/RHSA-2017:2787