Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5.5
-
None
Description
While importing MariaDB 10.5 to Debian, I noticed that the test main.failed_auth_unixsocket fails on arch armhf and 386 (but arm64 or amd64) when the Debian autopkgtests run.
The test failure:
main.failed_auth_unixsocket w4 [ fail ]
|
Test ended at 2020-10-09 20:55:21
|
|
|
CURRENT_TEST: main.failed_auth_unixsocket
|
mysqltest: At line 18: query 'connect fail,localhost,$USER' failed with wrong errno 1045: 'Access denied for user 'debci'@'localhost' (using password: NO)', instead of 1698...
|
|
|
The result from queries just before the failure was:
|
update mysql.global_priv set priv=json_insert(priv, '$.plugin', 'unix_socket') where user='root';
|
flush privileges;
|
connect(localhost,USER,,test,MASTER_PORT,MASTER_SOCKET);
|
Full logs:
- i386 fail: https://ci.debian.net/data/autopkgtest/testing/i386/m/mariadb-10.5/7380360/log.gz
- armhf fail: https://ci.debian.net/data/autopkgtest/testing/armhf/m/mariadb-10.5/7380287/log.gz
- arm64 pass: https://ci.debian.net/data/autopkgtest/testing/arm64/m/mariadb-10.5/7380183/log.gz
- amd64 pass: https://ci.debian.net/data/autopkgtest/testing/amd64/m/mariadb-10.5/7380101/log.gz
This did not occur with previous MariaDB 10.3 in Debian.
What are Debian autopkgtests?
See https://wiki.debian.org/ContinuousIntegration/autopkgtest
Debian has this massive CI system where each upload of a package triggers CI testing of other packages that depend on it: https://ci.debian.net/status/
The tests mariadb-10.5 runs are in the path debian/tests.
In MariaDB 10.5 we run mtr from the debian/tests/upstream test to re-use the existing test suite. Why this seems to end differently on debci from when run in post-build armhf and i386 builds is unknown.
On Debian buildd post-build mtr passes on main.failed_auth_unixsocket fine, e.g.
- https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=armhf&ver=1%3A10.5.5-3&stamp=1602238411&raw=0
- https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=i386&ver=1%3A10.5.5-3&stamp=1602231329&raw=0
Debci regressions are also automatically listed on the package tracker page and prevents unstable->testing migration:
https://tracker.debian.org/pkg/mariadb-10.5
Potential solutions
Maybe the error code 1045 is just fine and test can be extended to accept it?
Or we can in Debian skip this one test in the autopkgtests to ignore it.
Previous work
The test ./mysql-test/main/failed_auth_unixsocket.* has been touched in the past by sanja and serg
Attachments
Activity
Nope, the approach above does will not work. Next, looking at wrapper:
/**
|
a helper function to report an access denied error in most proper places
|
*/
|
static void login_failed_error(THD *thd)
|
{
|
my_error(access_denied_error_code(thd->password), MYF(0),
|
thd->main_security_ctx.user,
|
thd->main_security_ctx.host_or_ip,
|
thd->password ? ER_THD(thd, ER_YES) : ER_THD(thd, ER_NO));
|
general_log_print(thd, COM_CONNECT,
|
ER_THD(thd, access_denied_error_code(thd->password)),
|
thd->main_security_ctx.user,
|
thd->main_security_ctx.host_or_ip,
|
thd->password ? ER_THD(thd, ER_YES) : ER_THD(thd, ER_NO));
|
status_var_increment(thd->status_var.access_denied_errors);
|
/*
|
Log access denied messages to the error log when log-warnings = 2
|
so that the overhead of the general query log is not required to track
|
failed connections.
|
*/
|
if (global_system_variables.log_warnings > 1)
|
{
|
sql_print_warning(ER_THD(thd, access_denied_error_code(thd->password)),
|
thd->main_security_ctx.user,
|
thd->main_security_ctx.host_or_ip,
|
thd->password ? ER_THD(thd, ER_YES) : ER_THD(thd, ER_NO));
|
}
|
}
|
Could the code above have something that behaves differently in armhf/i386 on debci vs amd64 on debci?
Or maybe this? At least the comment field looks fishy:
if (!mpvio->acl_user)
|
{
|
/*
|
A matching user was not found. Fake it. Take any user, make the
|
authentication fail later.
|
This way we get a realistically looking failure, with occasional
|
"change auth plugin" requests even for nonexistent users. The ratio
|
of "change auth plugin" request will be the same for real and
|
nonexistent users.
|
Note, that we cannot pick any user at random, it must always be
|
the same user account for the incoming sctx->user name.
|
*/
|
ulong nr1=1, nr2=4;
|
CHARSET_INFO *cs= &my_charset_latin1;
|
cs->hash_sort((uchar*) sctx->user, strlen(sctx->user), &nr1, &nr2);
|
|
|
mysql_mutex_lock(&acl_cache->lock);
|
if (!acl_users.elements)
|
{
|
mysql_mutex_unlock(&acl_cache->lock);
|
login_failed_error(mpvio->auth_info.thd);
|
DBUG_RETURN(1);
|
}
|
This has not been assigned to anybody, and unlikely to be fixed in a reasonable amount of time, so I'll try to hack around the issue by selectively disabling this test in https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/74601f8b31a6c59e825089c52a1ca21545062813
strace form nikitamalyavin (Arch)
The strace shows it doesn't lookup the unix socket user using a syscall before issuing the denial. Odd.
SO_PEERCRED (getsockopt)
FYI eworm
This is still unsolved and unassigned. Maybe julien.fritsch wants to decide if it needs to be fixed or not?
I will now try https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/f452db78a6b0df2f8003b2d75e7d8b2a48a34a2a
--- a/sql/sql_acl.h+++ b/sql/sql_acl.h@@ -66,7 +66,7 @@ static inline int access_denied_error_coreturn 0;#elsereturn passwd_used == 2 ? ER_ACCESS_DENIED_NO_PASSWORD_ERROR- : ER_ACCESS_DENIED_ERROR;+ : ER_ACCESS_DENIED_NO_PASSWORD_ERROR;#endif}--- a/sql/table.cc+++ b/sql/table.cc@@ -6376,7 +6376,7 @@ bool TABLE_LIST::prepare_view_security_cthd->security_ctx->priv_user,thd->security_ctx->priv_host);else- my_error(ER_ACCESS_DENIED_ERROR, MYF(0),+ my_error(ER_ACCESS_DENIED_NO_PASSWORD_ERROR, MYF(0),thd->security_ctx->priv_user,thd->security_ctx->priv_host,(thd->password ? ER_THD(thd, ER_YES) :