Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
None
-
None
-
Windows
Description
MDEV-30487 showed example of missing test case with skip-name-resolve and anonymous user in mtr.
When user connects with anonymous user, connection resolves to USERNAME on Windows only environment, rather to anonymous user.
This situation doesn't occur for non-Windows OS-es.
It may be expected behavior, but I didn't find any reference about in KB.
By testing, this may be related to libmariadb client authentication here where USERNAME is read instead of mysql->user, for which mysql->user[0]='', and I guess because of function read_user_name implementation on Windows, that is using USERNAME.
Attachments
Issue Links
- relates to
-
-
- Open
-
Activity
read_user_name() returns the currently logged in user, if user name for mysql_real_connect() was not specified.
This behavior is the same on Windows and Posix systems:
mariadb -e"select current_user()" |
+-----------------+
|
| current_user() |
|
+-----------------+
|
| georg@localhost | |
+-----------------+
|
|
|
So I wonder which username do you expect on Windows, if none was specified?! |
user name not specified, is when NULL is passed to mysql_real_connect.
anonymous user is when "" is passed to mysql_real_connect.
Same behavior in MySQL, but it is documented:
https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-connect.html
"If user is NULL or the empty string "", the current user is assumed".
So yes, it's missing in our documentation.
By testing I noted that combination anonymous user + skip-name-resolve fails on buildbot and only on Windows (below is proof).
Without skip-name-resolve it works (bb doesn't fail, have seen in bb, but don't have proof to show here since used same branch for testing- can do on other branch, if you want).
I understand resolving of USERNAME, but we have uncovered test case in our suite (anonymous user + skip-name-resolve )
1. Without skip-name-resolve, here we still have anonymous user, buildbot doesn't fail.
I have test case (tested before, verified on bb): https://github.com/MariaDB/server/commit/3b3aa81df64fd9ead56d8b5d1e3325c311d51cea#diff-4f7e5eb7561bba054403ee3a773b92c8bfc44cb1640122d4890e12f8708026b2
2. With skip-name-resolve it fails (only on Windows) - here we may have a bug/or undocumented behavior:
Test case: https://github.com/MariaDB/server/commit/6846913c9fecb7de3eae3470300c16c87c03a591
Failure: https://buildbot.mariadb.org/#/builders/234/builds/15431
See all builds for this case: https://buildbot.mariadb.org/#/grid?branch=bb-10.5-anel-anonymous-user-windows-check
Just wanted to point that mtr is missing this test case to cover and we have failure on buildbot only on Windows.
In order to cover the test case ( anonymous user + skip-name-resolve ), what do you suggest to change in above test case (case 2.) ?
Based on statement [1] for Win and if in buildbot user is verified to be an Adminstrator as an current user, when skip-name-resolve is used, and if this is not a bug, should we have in mtr test pseudo-code like so:
# we are using skip-name-resolve |
if OS == Windows |
# anonymous user in bb == 'Administrator', since current user name must be specified explicitly for Windows (see [1]) and we are using skip-name-resolve |
connect('Adminstrator', localhost,,) |
else
|
# yes we can use anonymous user |
connect('',localhost,,,) |
[1] https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-connect.html
"If user is NULL or the empty string "", the current user is assumed". we have this too:
"Under Windows ODBC, the current user name must be specified explicitly. "
I derive from looking at the code and from Georg's answer, that there is no anonymous user possible, with Connector C, because connector C does not send empty string. So, I'm not sure what's tested here. What you assume as anonymous is probably root@localhost, or root@127.0.0.1, or root@::1 .
(I'm not commenting, whether localhost is or should be 127.0.0.1 or ::1, with or without skip-name-resolve, I do not care, to me it is the same thing 
)
anelThe situation does very well occur on non-Windows OSes, but in your environment read_user_name probably resolves to "root", and you accidentally are able to connect with that user and empty password.