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 :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.
The result of the authentication should be ignored but the scramble that
is calculated as a side-effect still needs to be stored. This can be done
by altering the SQL used to get the matching row to only match on the
username, not the network address.
Also expanded the test case to cover the use of bad credentials.
When users were loaded, the permissions for the service user were
checked. The conditional that makes sure the check is executed only at
startup was checking the listener's users instead of the SQLite handle
which caused all reloads of users to check the permissions.
When log messages are written with both address and port information, IPv6
addresses can cause confusion if the normal address:port formatting is
used. The RFC 3986 suggests that all IPv6 addresses are expressed as a
bracket enclosed address optionally followed by the port that is separate
from the address by a colon.
In practice, the "all interfaces" address and port number 3306 can be
written in IPv4 numbers-and-dots notation as 0.0.0.0:3306 and in IPv6
notation as [::]:3306. Using the latter format in log messages keeps the
output consistent with all types of addresses.
The details of the standard can be found at the following addresses:
https://www.ietf.org/rfc/rfc3986.txthttps://www.rfc-editor.org/std/std66.txt
When MaxScale is being started and the users are loaded, the MySQL
authenticator should not load the database users for internal services
abstracted as servers.
The loading of users at startup for internal services is avoided because
the startup is done in a single thread context and the internal services
have not yet been started.
The delayed loading of users will cause the authentication to fail when
the first client connect. This triggers the reloading of the users and the
second attempt at authentication will succeed. All of this is hidden from
the end user.
The static capabilities declared in getCapabilities allows certain
capabilities to be queried before instances are created. The intended use
of this capability is to remove the need for the `is_internal_service`
function.
Both the listeners and servers now support IPv6 addresses.
The namedserverfilter does not yet use the new structures and needs to be
fixed in a following commit.
The SQLite database is now always created on disk. This will remove the
need to dump the database users from the in-memory database to the
persisted on-disk database.
This change will also make the authentication compatible with older SQLite
implementations which lack the URI-based database strings found in newer
versions.
The authenticators should have a similar way to print diagnostic
information as filter and routers do. This allows the authenticators to
print the users in their own format.
In the future, all the diagnostic entry points should be changed so that
they return a structure that contains the information in a standard
form. This information can then be formatted in different ways by other
modules.
The get_users function now combines the functionality of the old get_users
and get_all_users. This removes large parts of similar code.
Removed the listener resources as MySQLAuth was the only one that used it.
The user data is now stored inside a SQLite3 database. By storing the data
inside a database, we remove the restriction that the previous hashtable
based implementation had.
Currently the only situation where a user needs to be authenticated after
the initial authentication is when a COM_CHANGE_USER is being
executed. This was previously handled by directly calling a function in
the MySQLAuth authenticator.
The new entry in the API of the authenticators is very specific to MySQL
and should be reviewed once other protocols are added.
