MySQL Bugs: #52197: Data permissions not set after mysql_install

Bug #52197	Data permissions not set after mysql_install_db
Submitted:	19 Mar 2010 1:01	Modified:	8 Dec 2016 9:29
Reporter:	Lee Clemens	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S3 (Non-critical)
Version:	5.1.45	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Even with --user being set during configure, if mysql_install_db is executed as root, the data directory's permissions are not set correctly and mysql will fail to start

How to repeat:
Install MySQL Server and define a non-root user during ./configure.
Then run mysql_install_db as root (or probably any user other than the service account specified during ./configure)

Suggested fix:
--user is specified when configure is executed, so it seems reasonable that mysql_install_db can set the file permissions correctly when they are created the first time.

Perhaps this is more of a feature request, but Google "Can't find file: './mysql/host.frm'", I'm obviously not the only one who has encountered this easily avoidable error. I feel the installer (mysql_install_db) should be responsible for such an action and setting the correct ownership on files it is creating.

Thank you for the bug report.

[root@hegel 5.1]# scripts/mysql_install_db 
Installing MySQL system tables...
OK
Filling help tables...
OK

To start mysqld at boot time you have to copy

[miguel@hegel ~]$ dbs/5.1/libexec/mysqld
100319  9:38:02 [Warning] Can't create test file /home/miguel/dbs/5.1/var/hegel.lower-test
100319  9:38:02 [Warning] Can't create test file /home/miguel/dbs/5.1/var/hegel.lower-test
dbs/5.1/libexec/mysqld: Can't change dir to '/home/miguel/dbs/5.1/var/' (Errcode: 13)
100319  9:38:02 [ERROR] Aborting

100319  9:38:02 [Note] dbs/5.1/libexec/mysqld: Shutdown complete

Quoting the manual page of mysql_install_db:

"
Because the MySQL server, mysqld, needs to access the data directory when it runs later, you should
       either run mysql_install_db from the same account that will be used for running mysqld or run it as
       root and use the --user option to indicate the user name that mysqld will run as. 
"

Did you follow these instructions or does the described behaviour only occur when they are not being followed?

My mistake, I did not run install_db with the --user option.  Although, the binaries have already been compiled with the specific --user option supplied when configure was run, seems redundant?

Looking at this again leads me to see this as a bug after all. While it is documented that specifying --user when running mysql_install_db is necessary to make installed files owned by the user mysqld is supposed to run as, and that the script must run as root for this to work, it is likewise documented that failure to specify --user leads to the files being owned by the current user. This does not actually work because mysqld will refuse to run as root if it is not explicitly told to by way of its own --user option, and mysql_install_db doesn't specify --user on its own. Hence, mysqld refuses to start and doesn't create the database files. It's not a permission problem; the files shouldn't even be there. This means that the only case where making the --with-mysqld-user value from configure the default actually has an impact - running mysql_install_db without --user as root - does not even work at this time. The other possible fix, making mysql_install_db explicitly tell mysqld to run as root so the database files will be owned by root if no --user is specified instead of a silent failure, is less desirable because we don't recommend running mysqld as root. The script should exit with an error if it is running as root and no default --user is available.

Posted by developer:
 
This could have been a useful improvement, but with the time that has passed, the importance of mysql_install_db is much diminished: MySQL 5.7 and newer do not use mysql_install_db on any platform, and the main delivery vehicle for MySQL on Windows is the new MySQL Installer for Windows, which does not employ mysql_install_db for any version of MySQL. Weighing that against the risk and effort of fixing this properly, I am closing this as Not feasible to fix.