Bug 1477575

Summary: service start fails due to wrong selinux type of logfile
Product: Red Hat Software Collections Reporter: Karel Volný <kvolny>
Component: mysqlAssignee: Michal Schorm <mschorm>
Status: CLOSED ERRATA QA Contact: Karel Volný <kvolny>
Severity: urgent Docs Contact:
Priority: urgent    
Version: rh-mysql56CC: databases-maint, hhorak, mmuzila
Target Milestone: alpha   
Target Release: 2.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
 Story Points: ---
Clone Of: Environment:
Last Closed: 2017-09-21 07:42:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1445537    
Attachments:
Description Flags
proposed patch with restorecon call none

Description Karel Volný 2017-08-02 12:10:41 UTC 
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 ...
Comment 2 Honza Horak 2017-08-03 09:50:22 UTC 
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.
Comment 7 errata-xmlrpc 2017-09-21 07:42:41 UTC 
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