mysqld.log file rights

When I installed Percona XtraDB Cluster 5.7 on CentOS 7.6, I noticed that the /var/log/mysqld.log file has -rwxr-xr-x DAC rights with a mysqld_log_t type owned by mysql:mysql. This seemed excessive (both because I can’t think of a reason to have execute rights on a log file and because it’s almost unheard of for a log file to be world readable) so I installed 5.7 community from the Oracle repo to compare. In that version the label and ownership are the same, but the DAC is -rw-r----- which seems more appropriate for a log file to me.

Does anyone know why the log file in Percona’s fork would be executable or DAC world readable? If it’s necessary, I can rely on other compensating controls, but if it’s not my defense in depth instincts would like to set those rights to match the Oracle version. In the absence of a reason, has anyone had any issues making this change (i.e. the rights are actually necessary) or is it one of those things that got set that way during a troubleshoot and never got set back? If I had a nickel for every one of those… :slight_smile:



I’m sorry, I meant to say it’s almost unheard of for an APPLICATION log file to be world readable. There are multiple OS log files that are world readable for various good (and good-ish) reasons, but most application packages make their logs owner read-write and (often, but not always) group readable.

FYI, in case anyone comes across this in searching for the same question, I changed the DAC rights on /var/log/mysqld.log from 755 to 600 and nothing seems to have a problem with it. I ran some CREATE, ALTER and DROP DDL statements, used the database to do standard SELECT, INSERT, UPDATE and DELETE DML statements and forced both SST and IST syncs all with no issues and everything I expected to see in the log file showing up. Logrotate needed a little tweaking, but it also rotates the logs properly.