If a client connects from an IPv4 address, but the listener listens on an
IPv6 address, the client IP will be a IPv6 mapped IPv4 address
e.g. ::ffff:127.0.0.1. A grant for an IPv4 address should still match an
IPv6 mapped IPv4 address.
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.
If a server points to a local MaxScale listener, the permission checks for
that server are skipped. This allows permission checks to be used with a
mix of external servers and internal services.
The static module capabilities are now used to query the capabilities of
filters and routers. The new RCAP_TYPE_NOAUTH capability is also taken
into use. These changes removes the need for the `is_internal_service`
function.
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.
The connector plugin directory can now be controlled with the
`connector_plugindir` argument and configuration option. This should allow
the connector to use the system plugins if the versions are binary
compatible.
Replaced calls to mysql_options to mysql_optionsv as the former is
deprecated in Connector-C 3.0 and the latter is supported in Connector-C
2.3.
The client protocol module can resolve whether a password was used based
on the information the authenticators gather before authentication is
done. It uses the authentication token length as the basis on which it
makes the decision.
The users were deleted before each individual server was queried. This
caused authentication to fail if the authentication data was loaded from
multiple servers.
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.
MariaDB and others match grants first by exact hostname/IP and then by
wildcard. If there are no exact matches, the wildcard grant should be
picked. This can be tested by having different passwords for localhost and
remote address.
The SQLite based authentication should first check for an exact match and
then only after that should it try to match the hostname to a wildcard
grant.
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.
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.
