MySQL Bugs: #117236: Resolving localhost in IPv4 and IPv6 dual-stack machines

Bug #117236	Resolving localhost in IPv4 and IPv6 dual-stack machines
Submitted:	18 Jan 16:36	Modified:	20 Jan 13:01
Reporter:	Pallieter Koopmans	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Security: Privileges	Severity:	S4 (Feature request)
Version:	8.0	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	8.0

Description:
When resolving localhost, consider RFC8305 and resolve ::1, 127.0.0.1, ::ffff:127.0.0.1 (IPv4 expressed as IPv6), and localhost using the same privilege.

A reason to solve this is that a lot of people ar enot setting up dual-stack environments and because of the Happy Eyeballs approach, IPv6 will (in modern systems) be the first (or default) response.

See, for example, this Virtualmin post that runs into this problem: https://forum.virtualmin.com/t/mariadb-privileges-ipv6-to-resolve-localhost/131641

How to repeat:
Compare results of:

GRANT ALL PRIVILEGES ON `databasename`.* TO 'username'@'::1';

vs

GRANT ALL PRIVILEGES ON `databasename`.* TO 'username'@'127.0.0.1';

vs

GRANT ALL PRIVILEGES ON `databasename`.* TO 'username'@'localhost';

on Debian 11 with IPv6 set up.

Suggested fix:
One solution could be adding a placeholder like localmachine to represent the group - as to not break backward compatibility of existing security setups that handle domains and/or IP addresses differently.

Personally, I recommend treating the 4 concepts of localhost equally (and in the same way the getaddrinfo() command would). So no matter which localhost equivalent  in a privilege statement an admin assigns via GRANT's hostname argument, the result should be the same.

Note: skip-name-resolve might need to ignore/bypass "localhost" going via a lookup (as the only domainname exception).

Current behavior is unexpected and confusing for users who are not deeply familiar with the nuances of IPv4/IPv6 and MySQL's privilege system.

And because often % is recommended as a solution to make life easier, this reduces overall "security by default" (as many scripts will use that to ensure they work in all cases).

PS: the error one gets is "ERROR 1045 (28000): Access denied for user".

HI Mr. Koopmans,

Thank you for your bug report.

However, we aer not able to repeat it .

What we require is a full test case. This includes how to configure IPv4 to act like IPv6 on any operating system. We need a precise set of instructions.

Then we have try to set up privileges as described in your report.

Can't repeat.

HI Mr. Koopmans,

You are partially correct regarding your bug report.

This is a documented behavior: https://dev.mysql.com/doc/refman/8.4/en/account-names.html. 

However,  it is a feature request ... ::1 a shortcut (from 0:0:....:1) for loopback address in IPv6. Similar to 127.0.0.1 for IPv4. And the should both resolve to "localhost" symbol.  But the IPv6 version doesn't. I.e. if you connect via IPv6 you don't get the privileges granted to @localhost.

Verified as a feature request.