If a machine where MariaDB server RPM is installed contains my.cnf with values that are not valid for the current version of the server, the installation process fails to detect correct values of basedir and datadir, ends up with datadir=/ and changes ownership of the entire system to mysql:mysql. For details about the fragment of the post-install script see the original description below.

It can especially easily happen on a downgrade, but crossgrade and even upgrade can cause it too, if the problematic value was either deprecated and removed, or just became invalid due to different server build options or configuration (e.g. different character sets).

Reproducible on MariaDB 5.5.28a and 10.0.0. Installation of 5.1-5.3 doesn't seem to have the disastrous effect, and neither does MySQL 5.5.29.

My suggestion is to check whether mysqld help produced any results for basedir and datadir, and if not, abort further process since the installation obviously doesn't work as expected.

Please also consider a request for an additional sanity check in the comment.

======================

Original description

The MariaDB-Server RPM appears to contain a flawed method of determining mysql 'datadir' path.

This is in the post-install scriptlet packaged in the RPM for both the centos5 and centos6 versions, and both 64bit and 32bit packages.

Relevant part of the post-installation shell scriptlet:

mysql_dirs=(`/usr/sbin/mysqld --verbose --help 2>/dev/null|sed -ne 's/^\(basedir\|datadir\)[[:space:]]*\(.*\)$/\2/p'`)

basedir="${mysql_dirs[0]}"

datadir="${mysql_dirs[1]}"

  # datadir may be relative to a basedir!

if expr $datadir : / > /dev/null; then

  mysql_datadir=$datadir

else

  mysql_datadir=$basedir/$datadir

fi

In my testing, the initial shell array, $mysql_dirs is empty when that command is run. Thus mysql_datadir="/"

This is dangerous because the subsequent use of the variable is:

chown -R mysql:mysql $mysql_datadir

On the centos6 server, moving /etc/my.cnf to /etc/my.cnf.TMP ahead of time, makes the initial population of $mysql_dirs[@] to be correct. (not sure why yet)

On the centos5 server it's the same deal, however, moving the my.cnf causes the array to populate, but it still produces incorrect path values:

mysql_dirs[0] => .

mysql_dirs[1] => /

I don't have a suggestion at the moment for how to fix, although I believe there must be a better way to find the mysql datadir than the current implementation.

I hope this is the right place to submit this bug. I marked it critical because chowning the entire filesystem mysql:mysql recursively is fairly catasthropic.