Red Hat Bugzilla – Bug 143887
mysqld can't append to /var/log/mysqld.log due to selinux
Last modified: 2013-07-02 23:03:06 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: After installing the mysql-server package (which is not without problems also, see bugzilla entry id=141062) messages in /var/log/messages indicate that mysqld has problems appending information to /var/log/mysqld.log. A typical message is: Dec 31 18:27:48 lt2 kernel: audit(1104514068.391:0): avc: denied { append } for pid=22697 exe=/usr/libexec/mysqld path=/v ar/log/mysqld.log dev=hda6 ino=79669 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_log_t tclass=file The file /var/log/mysqld.log contains only 1 (one) line like: 041231 18:27:48 mysqld started Version-Release number of selected component (if applicable): mysql-server-3.23.58-13 How reproducible: Always Steps to Reproduce: 1.service mysqld start 2.check /var/log/messages for stuff related to mysqld.log 3.check /var/log/mysqld.log Actual Results: /var/log/messages contains several messages indicating the mysqld has problems accessing /var/log/mysqld.log. /var/log/mysqld.log contains very little information other then that mysqld has started. Expected Results: No such messages in /var/log/messages Perhaps a bit more information in /var/log/mysqld.log. If I disable selinux for mysqld it contains a lot more, like: 041231 18:20:18 mysqld started Cannot initialize InnoDB as 'innodb_data_file_path' is not set. If you do not want to use transactional InnoDB tables, add a line skip-innodb ... Additional info: It seems that /etc/init.d/mysqld creates /var/log/mysqld.log in such a way that its selinux "profile" (pardon me the expression, I am no selinux expert) differs from what mysqld expects.
In bugzilla enry id=141062 selinux is enabled and disabled using setenforce. But that is like cracking a nut with a sledgehammer. It can be done more fine grain for mysqld only with "system-config-securitylevel" on the "SELinux" tab under "SELinux Service Protection" by selecting the "Disable SELinux protection for mysqld deamon".
I looked a bit further into the suggestion of bugzilla entry id=141062 to use "restorecon". After using it on /var/log/mysqld.log the original problem was gone, even with SELinux fully enabled. So there is a workaround (Disable SELinux protection for mysqld deamon) and a fix (restorecon /var/log/mysqld.log). But the problem still needs to be solved. The way that /var/log/mysqld.log is created and gets its security credentials needs to be changed (in the RPM scripts, probably).
This is already repaired in development tip, by doing this just after the chown/chmod of the error log file: [ -x /sbin/restorecon ] && /sbin/restorecon "$errlogfile" However I have been hoping to resolve what's happening in bug #141062 before releasing another FC3 update. There seems to be some factor involved there that I can't reproduce :-(
I've pushed out this fix for FC3 in mysql-3.23.58-14. It will need to be patched in RHEL4 as well.
This is now fixed in a pending RHEL4 update.