| 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: | |
| 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
[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:"
