Description of problem: By default the datadir for installs of mariadb-server (or mysql-server for centos6) is set to /var/lib/mysql. It has '755' set as the permissions for this directory. This is contrary to the MySQL secure deployment guide https://dev.mysql.com/doc/mysql-secure-deployment-guide/8.0/en/secure-deployment-permissions.html which states the data directory should not have world read/execute permissions. How reproducible: Always Steps to Reproduce: 1. yum install mariadb-server 2. ls -l /var/lib | grep mysql Actual results: drwxr-xr-x 5 mysql mysql 159 Jul 2 09:34 mysql Expected results: drwxr-x--- 5 mysql mysql 159 Jul 2 09:34 mysql Additional info: Tested on centos 6 and 7, appears to be the default config for both. Not yet tested on centos 8. (Initially reported on CentOS bugtracker, was referred here.)
Thanks for the report. This indeed doesn't seem ideal, however, we're storing the unix socket in that directory, so if we change the permissions, any non-root and non-mysql user cannot connect, as seen in this reproducer: ------------------------------------- Reproducer: # install and run the server $> sudo yum install -y mariadb-server mariadb $> sudo service mariadb start # create a non-root user and verify it can connect $> sudo useradd testuser $> su - testuser -c 'echo SELECT 42 | mysql' 42 42 # check the permissions of the data directory $> ls -ld /var/lib/mysql drwxr-xr-x. 5 mysql mysql 177 Aug 16 06:39 /var/lib/mysql # Change the permissions to 0700 $> sudo chmod 0700 /var/lib/mysql $> ls -ld /var/lib/mysql drwx------. 5 mysql mysql 177 Aug 16 06:39 /var/lib/mysql # Check whether the non-root user can connect $> su - testuser -c 'echo SELECT 42 | mysql' ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13) ------------------------------------- I'm not personally sure whether this is worth changing, considering users can always move the data directory elsewhere and also that both, unix socket location and datadir are de-facto API of the server that users depend on.. Let's think about it more though.. I see two options now, both pretty disruptive to existing scenarios, so it wouldn't be possible to do in current releases, we might fix it for RHEL-next though: 1) move the data directory itself into a sub-directory (same as we do it in postgresql): /var/lib/mysql/data 2) move the socket somewhere else than the MariaDB data dir Any other options, anybody?
For what it's worth, my vote would be for option 1 as it makes sense to move the socket file into /var/run/(mysql|mariadb)/ anyway. Splitting out the data directory is a nice "neatness" bonus, but I don't think it carries any other benefits by itself.
Moving to Fedora, because whatever change we do (if any), it will be done there first, we cannot change this in existing RHEL any more.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
For comparison, this is the status in Ubuntu 20.04: ``` # dpkg -l | grep mariadb ii mariadb-client-10.3 1:10.3.29-0ubuntu0.20.04.1 amd64 MariaDB database client binaries ii mariadb-client-core-10.3 1:10.3.29-0ubuntu0.20.04.1 amd64 MariaDB database core client binaries ii mariadb-common 1:10.3.29-0ubuntu0.20.04.1 all MariaDB common metapackage ii mariadb-server-10.3 1:10.3.29-0ubuntu0.20.04.1 amd64 MariaDB database server binaries ii mariadb-server-core-10.3 1:10.3.29-0ubuntu0.20.04.1 amd64 MariaDB database core server files # ls -la /var/lib/mysql total 110616 drwxr-xr-x 1 mysql mysql 230 May 23 06:38 . drwxr-xr-x 1 root root 52 May 23 06:38 .. -rw-rw---- 1 mysql mysql 16384 May 23 06:38 aria_log.00000001 -rw-rw---- 1 mysql mysql 52 May 23 06:38 aria_log_control -rw-r--r-- 1 root root 0 May 23 06:38 debian-10.3.flag -rw-rw---- 1 mysql mysql 972 May 23 06:38 ib_buffer_pool -rw-rw---- 1 mysql mysql 50331648 May 23 06:38 ib_logfile0 -rw-rw---- 1 mysql mysql 50331648 May 23 06:38 ib_logfile1 -rw-rw---- 1 mysql mysql 12582912 May 23 06:38 ibdata1 drwx------ 1 mysql mysql 2708 May 23 06:38 mysql drwx------ 1 mysql mysql 12 May 23 06:38 performance_schema ``` While the data dir top level is all-readable, the files inside it are not. On Debian/Ubuntu the socket has always been in (/var)/run/mysqld.sock . If you think this is a security issue, I suggest you raise it with upstream http://jira.mariadb.org/ and don't just silently "fix" it for Fedora without coordination. The less there is delta to upstream, the less you need to maintain custom stuff in the future.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.