Bug #32542 mysql_install_db: Post-install instructions not complete
Submitted: 20 Nov 2007 19:30 Modified: 13 Oct 2016 12:17
Reporter: Paul Dubois Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Server: Installing Severity:S3 (Non-critical)
Version:5.0 and up OS:Any
Assigned to: Assigned Account CPU Architecture:Any

[20 Nov 2007 19:30] Paul Dubois
Description:
After mysql_install_db initializes the data directory, it produces some instructions about setting the root account passwords (here, polar.kitebird.com is the machine on which I ran the command):

% bin/mysql_install_db
Installing MySQL system tables...
OK
Filling help tables...
OK

To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/var/mysql/50054/bin/mysqladmin -u root password 'new-password'
/var/mysql/50054/bin/mysqladmin -u root -h polar.kitebird.com password 'new-password'

However, the data directory initialization process now includes *three* root accounts:

mysql> SELECT Host, User, Password from mysql.user;
+--------------------+------+----------+
| Host               | User | Password |
+--------------------+------+----------+
| localhost          | root |          |
| polar.kitebird.com | root |          |
| 127.0.0.1          | root |          |
| localhost          |      |          |
| polar.kitebird.com |      |          |
+--------------------+------+----------+
5 rows in set (0.00 sec)

Thus, running the two mysqladmin commands to set the root account passwords leaves one of those accounts without a password. This leaves the installation insecure when a user follows our instructions for securing the installation.

How to repeat:
See above.

Suggested fix:
I suppose we either need to not create the root@127.0.0.1 account, or modify the instructions to show how to set the passwords for all three root accounts.
[20 Nov 2007 19:41] MySQL Verification Team
Thank you for the bug report. Verified as described.

Server version: 5.0.52-debug Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> SELECT Host, User, Password from mysql.user;
+-----------+------+----------+
| Host      | User | Password |
+-----------+------+----------+
| localhost | root |          | 
| skybr.net | root |          | 
| 127.0.0.1 | root |          | 
| localhost |      |          | 
| skybr.net |      |          | 
+-----------+------+----------+
5 rows in set (0.00 sec)
[29 Sep 2009 14:23] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/85037

2883 Jonathan Perkin	2009-09-29
      bug#32542: mysql_install_db: Post-install instructions not complete
      
      Remove the '127.0.0.1' root account by default, the 'localhost' account
      should be sufficient.
[29 Sep 2009 17:57] Joerg Bruehe
To me, it seems the line for host "127.0.0.1" is essential, because the file contains a comment:
-- When setting up a "cross bootstrap" database (e.g., creating data on a Unix
-- host which will later be included in a Windows zip file), any lines
-- containing "@current_hostname" are filtered out by mysql_install_db.

If that comment is still valid (which I did not check), then the 127.0.0.1 line seems to be necessary on Windows.

Even if that should be invalid now, I don't know when the server sees a local client as connecting from "localhost" and when from "127.0.0.1", and I would rather not decide this just based on some local experiments of mine.

I propose to get some Support colleagues to judge that, I do not consider this entry to be a sufficient review (especially as a non-Windows user).

Note that it is relevant only with a new installation, not with an upgrade:
In file "scripts/mysql_system_tables.sql", a variable "@had_user_table" is set if there was a "user" table originally ("create table if not exists ..."), which is evaluated here:
INSERT INTO user SELECT * FROM tmp_user WHERE @had_user_table=0;
[29 Sep 2009 19:15] Joerg Bruehe
Sorry, I must have been blindfolded - please ignore that part about "necessary", I considered "localhost" where the file comment clearly says "@current_hostname".

However, I'm still cautious we might need "127.0.0.1" somewhere (other than for a broken "/etc/hosts"), and so propose to check with Support.
[1 Oct 2009 22:11] Timothy Smith
Removing the '127.0.0.1' account is not acceptable, for this situation:

mysqld --skip-name-resolve

./mysql -h127.0.0.1
ERROR 1130 (HY000): Host '127.0.0.1' is not allowed to connect to this MySQL server

Both entries are needed, unfortunately.  The @localhost entry governs connections on the UNIX domain socket (named pipe, "/tmp/mysql.sock").  The @127.0.0.1 entry governs TCP/IP connections.

If --skip-name-resolve is NOT used, and there is no 127.0.0.1 entry, then mysql -h127.0.0.1 will connect via TCP, and use the @localhost entry for privilege info.  However, --skip-name-resolve is commonly used, and it is not acceptable to reject TCP connections on localhost in this case -- too many applications are likely to depend on this.

So, it appears we are stuck with having duplicate entries, and must simply encourage the user to update all of them.

An alternative would be to magically use @localhost for TCP connections to the loopback interface when no specific match is found for the IP address (nor for the hostname, if --skip-name-resolve is off).  I kind of like this idea, but it would be a feature request for a future MySQL release, probably.

Regards,

Timothy
[25 May 2010 17:53] Paul Dubois
The instructions about setting the root passwords are even more problematic as of 5.5.3, which adds a new root account to be created during MySQL installation: 'root'@'::1'.

Since the instructions do not mention this account as needing a password, or provide instructions for setting it, they are yet more incomplete leave the installation even more insecure.
[23 Nov 2012 10:37] Hartmut Holzgraefe
Five years, two lines of static text times two files ... how hard can it be?

Patch against todays public 5.5 bzr tree:

=== modified file 'scripts/mysql_install_db.pl.in'
--- scripts/mysql_install_db.pl.in	2012-02-15 16:21:38 +0000
+++ scripts/mysql_install_db.pl.in	2012-11-23 10:34:41 +0000
@@ -498,6 +498,8 @@
            "To do so, start the server, then issue the following commands:",
            "",
            "  $bindir/mysqladmin -u root password 'new-password'",
+           "  $bindir/mysqladmin -u root -h 127.0.0.1 password 'new-password'",
+           "  $bindir/mysqladmin -u root -h ::1 password 'new-password'",
            "  $bindir/mysqladmin -u root -h $hostname password 'new-password'",
            "",
            "Alternatively you can run:",

=== modified file 'scripts/mysql_install_db.sh'
--- scripts/mysql_install_db.sh	2012-02-16 09:48:16 +0000
+++ scripts/mysql_install_db.sh	2012-11-23 10:35:04 +0000
@@ -456,6 +456,8 @@
   echo "To do so, start the server, then issue the following commands:"
   echo
   echo "$bindir/mysqladmin -u root password 'new-password'"
+  echo "$bindir/mysqladmin -u root -h 127.0.0.1 password 'new-password'"
+  echo "$bindir/mysqladmin -u root -h ::1 password 'new-password'"
   echo "$bindir/mysqladmin -u root -h $hostname password 'new-password'"
   echo
   echo "Alternatively you can run:"