Due to MDEV-15556 and MDEV-15840 recursive CTEs can't be reliably used
with older 10.2 versions. To prevent problems, only use the query that
extracts composite roles with newer versions.
The authentication code did not initialize one of the buffers used to
calculate the password hashes. This resulted in the use of uninitialized
memory when the user provided no password.
If a 10.2.11 or older server without a grant on all mysql tables is found,
the authenticator now falls back to the 10.1 behavior that uses subqueries
instead of CTEs. This is a more user friendly way of working around
MDEV-13453 that causes the problem as all functionality except the support
for composite roles is retained.
If the password field in mysql.user is empty, it is possible that the
actual password is stored in the authentication_string field. Most of the
time this happens due to MDEV-16774 which causes the password to be stored
in the authentication_string field.
Also added a test case that verifies the problem and that it is fixed by
this commit.
Instead of looking at the server version, the actual error message should
be inspected. This guarantees that the correct error message is logged
even with custom builds.
When the 10.2 users query is executed with a MariaDB server older than
10.2.11, the query will fail due to inadequate grants on the 'users' table
generated as a part of the CTE. To work around the issue, a SELECT grant
on the whole mysql database is required. Logging the server where the
query fails also helps resolve the problem by pointing out where the grant
needs to be added.
Added support for composite roles for 10.2 and newer versions. As
recursive CTEs are required to extract the role mappings, composite roles
aren't supported on 10.1.
If a service has no active servers and users are injected, a warning would
be logged. This is a misleading warning if the service has no servers and
should only be logged if the failure to load any users is an unexpected
situation.
If the authentication failure was due to a missing database, this extra
information can be logged. This will help cases where users are using
databases that do not exist.
If the service user does not have adequate grants to the mysql tables, the
legacy query is used. This prevents an upgrade failure when the user was
lacking the new privileges.
If the reauthentication of a client that is performing a COM_CHANGE_USER
fails, the users need to be reloaded. Without the reloading, the
reauthentication will fail if new users were added after the last loading
of users.
We need to copy some data from a AF_UNIX based listener dcb
to the accepted client dcb, to prevent assertion violation in
dcb_get_port(). Further, to be able to log the path in the case
of an authentication error we need to copy that as well.
Earlier, if a service had multiple listeners you would have had
MaxScale> show dbusers MyService
User names: alice@% ...
User names: bob@% ...
That is, no indication of which listener is reporting what. With
this commit the result will be
User names (MyListener1): alice@% ...
User names (MyListener2): bob@% ...
Further, the diagnostics function of an authenticator is now expected
to write the list of users to the provided DCB, without performing any
other formatting. The formatting (printing "User names" and appending
a line-feed) is now handled by the handler for the MaxAdmin command
"show dbusers".
The message now states the impliciations of missing permissions. If the
MaxScale user does not have the permissions to view all databases, it will
only see its own databases.
MySQLAuth requires the SHOW DATABASES privilege to see all the databases
so it should be checked that the current user has the permission. A
missing permission will cause errors that are hard to resolve.
This is used only in case of everything else fails and this lookup
is not unlikely to fail if the client comes from some machine on
an internal network.
According to customer reports collecting the statistics has a significant
impact on the performance. As we don't need that information we can just
as well turn off that.
Further, since maxscale-common now links to the sqlite3-library, no
module needs to do that explicitly.
The list of users that is used for authentication shoudl only consist of
users that do not use an explicit authentication plugin. This way
authentication fails before any connections to the backend servers are
done.
Make all modules lowercase and make module loading case
insensitive. Further, make command invocation case insensitive,
as far as the module name is conserned.
When a client connects to MaxScale and authentication fails, an error
about hostname resolution is logged. This happens because the
authentication first tries to resolve the address as an IP address, then
an IPv6-mapped-IPv4 address and finally as a hostname. If users have not
been loaded, the authentication is guaranteed to fail on the first attempt
due to the lazy loading of users.
The :memory: database was misspelled as :memory without the trailing
colon. This caused an actual on-disk database to be created instead of an
in-memory one.
The thread-local user cache removes most of the cross-thread communication
from the user authentication at the cost of increased memory use and extra
network usage when users are loaded.
If the authenticator option is enabled, no users are loaded and no errors
have occurred in the user loading process, the service credentials are
injected.
