This plugin implements the inet4 data type and functions used by this data type, like conversions.

This plugin is built in to MariaDB Server. It cannot be disabled.

inet4 is a data type plugin. It can be used in stored procedures as a variable type and as a data type for table columns.

This plugin implements the nhnsw vector index algorithm. It is used to create vector indexes.

See Vector Overview for the functionality, and Vector System Variables for what you can configure.

It is built in the server, and is always enabled.

For plugin version and maturity level, see this page.

MariaDB supports the use of plugins, software components that may be added to the core software without having to rebuild the MariaDB server from source code. Plugins can be loaded at startup, or loaded and unloaded while the server is running, without interruption. Plugins are commonly used for adding desired storage engines, additional security requirements, logging special information about the server, or even small enhancements, such as a plugin to get a timestamp as an integer.

Querying Plugin Information

There are a number of ways to see which plugins are currently active.

A server almost always has a large number of active plugins, because the server contains a large number of built-in plugins, which are active by default and cannot be uninstalled.

MariaDB and MySQL are used in a broad range of environments, but if you needed to record user access to be in compliance with auditing regulations for your organization, you would previously have had to use other database solutions. To meet this need, though, MariaDB has developed the MariaDB Audit Plugin. Although the MariaDB Audit Plugin has some unique features available only for MariaDB, it can be used also with MySQL.

Basically, the purpose of the MariaDB Audit Plugin is to log the server's activity. For each client session, it records who connected to the server (i.e., user name and host), what queries were executed, and which tables were accessed and server variables that were changed. This information is stored in a rotating log file or it may be sent to the local syslogd.

Review these pages for detailed documentation:

There are a few status variables related to the , once it has been . These variables can be displayed using the statement like so:

Status Variables

Below is a list of all status variables related to the Audit Plugin. These cannot be set: These are not to be confused with system variables, which can be set. See for a complete list of status variables that can be viewed with the statement. See also the .

This plugin is for . It splits up the wsrep_provider_options setting into individual configuration variables.

Without that plugin, options are grouped together, like this:

With this plugin loaded, you can configure individual variables, like this:

This makes managing provider options easier, and helps avoid the problem of wsrep_provider_options exceeding the maximum length of 2048 characters for an individual variable.

The JSON type in MySQL stores the JSON object in its own native form, while, in MariaDB, the is a . Opening a table with a JSON type created in MySQL results in an error:

The mysql_json plugin is used to make it easier to upgrade to MariaDB.

This plugin represents the online alter log in a transaction. It is used to commit transactions for tables while an online ALTER TABLE query is running.

It is built in the server, and is always enabled.

See the Online Schema Change page for functionality details.

For plugin version and maturity level, see this page.

The password_reuse_check_interval system variable is available when the password_reuse_check plugin is installed. It determines the retention period for the password history in days. Zero, the default, means that passwords are never discarded.

• Command line: --password_reuse_check_interval=#

• Scope: Global

• Read-only: No

• Data Type: numeric

• Default Value: 0

• Range: 0 to 36500

_{This page is licensed: CC BY-SA / Gnu FDL}

The following table lists the various plugins included in MariaDB ordered by their maturity. Note that maturity will differ across MariaDB versions - see below for an easy way to get a complete list of plugins and their maturity in your version of MariaDB:

This query shows a complete list of plugins and their maturity level:

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

The mysql_old_password authentication plugin is the default authentication plugin that is used for an account created when no authentication plugin is explicitly mentioned and old_passwords=1 is set. It uses the pre-MySQL 4.1 password hashing algorithm, which is also used by the OLD_PASSWORD() function and by the PASSWORD() function when old_passwords=1 is set.

Installing the Plugin

The mysql_old_password authentication plugin is statically linked into the server, so no installation is necessary.

Creating Users

The easiest way to create a user account with the mysql_old_password authentication plugin is to make sure that is set, and create a user account via that does not specify an authentication plugin, but instead specifies a password via the clause:

If does not have NO_AUTO_CREATE_USER set, then you can also create the user via :

You can also create the user account by providing a password hash via the clause, and MariaDB validates whether the password hash is one that is compatible with mysql_old_password:

Similar to all other , you could also specify the name of the plugin in the IDENTIFIED VIA clause, while providing the password hash as the USING clause:

Changing User Passwords

You can change a user account's password with the statement, while providing the plain-text password as an argument to the function:

You can also change the user account's password with the statement. You have to make sure that is set, and you have to specify a password via the clause:

Client Authentication Plugins

For clients that use the libmysqlclient or libraries, MariaDB provides one client authentication plugin that is compatible with the mysql_old_password authentication plugin:

• mysql_old_password

When connecting with a to a server as a user account that authenticates with the mysql_old_password authentication plugin. You may need to tell the client where to find the relevant client authentication plugin by specifying the --plugin-dir option:

However, the mysql_old_password client authentication plugin is generally statically linked into client libraries like libmysqlclient or , so this is not usually necessary.

mysql_old_password

The mysql_old_password client authentication plugin hashes the password before sending it to the server.

Support in Client Libraries

The mysql_old_password authentication plugin is one of the conventional authentication plugins, so all client libraries should support it.

_{This page is licensed: CC BY-SA / Gnu FDL}

The audit plugin logs user access to MariaDB and its objects. The audit trail (that is, the audit log) is a set of records, written as a list of fields to a file in a plain‐text format. The fields in the log are separated by commas. The format used for the plugin's own log file is slightly different from the format used if it logs to the system log because it has its own standard format. The general format for the logging to the plugin's own file is defined like the following:

If the server_audit_output_type variable is set to syslog instead of the default, file, the audit log file format is as follows:

Various events result in different audit records. Some events do not return a value for some fields (for instance, when the active database is not set when connecting to the server).

Below is a generic example of the output for connect events, with placeholders representing data. These are events in which a user connected, disconnected, or tried unsuccessfully to connect to the server.

Here is the one audit record generated for each query event:

Below are generic examples of records that are entered in the audit log for each type of table event:

Passwords are hidden in the log for certain types of queries. They are replaced with asterisks for GRANT, CREATE USER, CREATE MASTER, CREATE SERVER, and ALTER SERVER statements. Passwords, however, are not replaced for the PASSWORD() and OLD_PASSWORD() functions when they are used inside other SQL statements (i.e., SET PASSWORD).

_{This page is licensed: CC BY-SA / Gnu FDL}

Below is a list of the releases of the MariaDB Audit Plugin, the most recent version first, and in which versions of MariaDB each plugin version was included.

_{This page is licensed: CC BY-SA / Gnu FDL}

The server_audit plugin logs the server's activity. For each client session, it records who connected to the server (i.e., user name and host), what queries were executed, and which tables were accessed and server variables that were changed. This information is stored in a rotating log file or it may be sent to the local syslogd.

Locating the Plugin

The server_audit plugin's shared library is included in MariaDB packages as the server_audit.so or server_audit.dll shared library on systems where it can be built.

The plugin must be located in the plugin directory, the directory containing all plugin libraries for MariaDB. The path to this directory is configured by the system variable. To see the value of this variable and thereby determine the file path of the plugin library, execute the following SQL statement:

Check the directory returned at the filesystem level to make sure that you have a copy of the plugin library, server_audit.so or server_audit.dll, depending on your system. It's included in recent installations of MariaDB. If you do not have it, you should upgrade MariaDB.

Installing the Plugin

Although the plugin's shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default. There are two methods that can be used to install the plugin with MariaDB.

The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing or :

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to mariadbd , or it can be specified in a relevant server in an :

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or :

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Prohibiting Uninstallation

The or statements may be used to uninstall plugins. For the server_audit plugin, you might want to disable this capability. To prevent the plugin from being uninstalled, you could set the option to FORCE_PLUS_PERMANENT in a relevant server in an after the plugin is loaded once:

Once you've added the option to the server's option file and restarted the server, the plugin can't be uninstalled. If someone tries to uninstall the audit plugin, then an error message will be returned. Below is an example of the error message:

For more information on FORCE_PLUS_PERMANENT and other option values for the option, see for more information.

_{This page is licensed: CC BY-SA / Gnu FDL}

The user_variables plugin creates the USER_VARIABLES table in the INFORMATION_SCHEMA database. This table contains information about user-defined variables.

Viewing

User-defined variables can be viewed by either querying the USER_VARIABLES, or by running SHOW USER_VARIABLES.

Flushing User-Defined Variables

User-defined variables are reset and the Information Schema table emptied with the statement.

Examples

Installing the Plugin

If it is not installed, however, here are two methods that can be used to install the plugin with MariaDB.

The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing or :

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an :

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or :

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Options

user_variables

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

_{This page is licensed: CC BY-SA / Gnu FDL}

The QUERY_CACHE_INFO plugin creates the QUERY_CACHE_INFO table in the INFORMATION_SCHEMA database. This table shows all queries in the query cache. Querying this table acquires the query cache lock and will result in lock waits for queries that are using or expiring from the query cache. You must have the PROCESS privilege to query this table.

Installing the Plugin

Although the plugin's shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default. There are two methods that can be used to install the plugin with MariaDB.

The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing or :

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an :

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or :

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Example

Options

query_cache_info

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

_{This page is licensed: CC BY-SA / Gnu FDL}

The mysql_native_password authentication plugin is the default authentication plugin that will be used for an account created when no authentication plugin is explicitly mentioned and is set. It uses the password hashing algorithm introduced in MySQL 4.1, which is also used by the function when is set. This hashing algorithm is based on .

It is not recommended to use the mysql_native_password authentication plugin for new installations that require high password security. If someone is able to both listen to the connection protocol and get a copy of the mysql.user table, then the person would be able to use this information to connect to the MariaDB server. The authentication plugin is a more modern authentication plugin that provides simple password authentication using a more secure algorithm.

After the audit plugin has been installed and loaded, there will be some new global variables within MariaDB. These can be used to configure many components, limits, and methods related to auditing the server. You may set these variables related to the logs, such as their location, size limits, rotation parameters, and method of logging information. You may also set what information is logged, such connects, disconnects, and failed attempts to connect. You can also have the audit plugin log queries, read and write access to tables. So as not to overload your logs, the audit plugin can be configured based on lists of users. You can include or exclude the activities of specific users in the logs.

To see a list of on the server and their values, execute the follow while connected to the server:

The values of these variables can be changed by an administrator with the SUPER privilege, using the statement. Below is an example of how to disable audit logging:

Although it is possible to change all of the variables shown above, some of them may be reset when the server restarts. Therefore, you may want set them in the configuration file (e.g.,

simple_password_check is a plugin. It can check whether a password contains at least a certain number of characters of a specific type. When first installed, a password is required to be at least eight characters, and requires at least one digit, one uppercase character, one lowercase character, and one character that is neither a digit nor a letter.

Note that passwords can be directly set as a hash, bypassing the password validation, if the variable is OFF (it is ON by default).

Background

MySQL 5.6 added support for the authentication plugin, and MySQL 8.0 also added support for the authentication plugin.

The caching_sha2_password plugin is now the default authentication plugin in MySQL 8.0.4 and above, based on the value of the system variable.

The PARSEC Authentication Plugin is intended to be the default in a future release.

The PARSEC (Password Authentication using Response Signed with Elliptic Curve) authentication plugin uses salted passwords, key derivation, extensible password storage format, and both server- and client-side scrambles.

It signs the response with ed25519, but it uses stock unmodified ed25519

The DISKS plugin creates the DISKS table in the INFORMATION_SCHEMA database. This table shows metadata about disks on the system. It required the FILE privilege.

Installing the Plugin

Although the plugin's shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default. There are two methods that can be used to install the plugin with MariaDB.

The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing or :

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an :

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or :

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Example

Versions

Options

disks

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

_{This page is licensed: CC BY-SA / Gnu FDL}

The WSREP_INFO plugin library contains the following plugins:

• WSREP_MEMBERSHIP

• WSREP_STATUS

The WSREP_MEMBERSHIP plugin creates the

The named_pipe authentication plugin allows the user to use operating system credentials when connecting to MariaDB via named pipe on Windows. Named pipe connections are enabled by the system variable.

The named_pipe authentication plugin works by using and calling GetUserName() to retrieve the user name of the process that is connected to the named pipe. Once it has the user name, it authenticates the connecting user as the MariaDB account that has the same user name.

Description

The plugin is used to prevent a user from reusing a password, which can be a requirement in some security policies. The system variable determines the retention period, in days, for a password. By default, this is zero, meaning unlimited retention. Old passwords are stored in the .

Note that passwords can be directly set as a hash, bypassing the password validation, if the variable is OFF (it is ON by default).

Installing the Plugin

Although the plugin's shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default.

You can install the plugin dynamically, without restarting the server, by executing or :

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an :

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or :

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Example

Versions

See Also

• (MariaDB Foundation blog post)

_{This page is licensed: CC BY-SA / Gnu FDL}

We walk through the configuration of PAM authentication using the pam authentication plugin and user and group mapping with the pam_user_map PAM module. The primary authentication will be handled by the pam_unix PAM module, which performs standard Unix password authentication.

Hypothetical Requirements

In this walkthrough, we are going to assume the following hypothetical requirements:

• The Unix user foo should be mapped to the MariaDB user bar. (foo: bar)

• Any Unix user in the Unix group dba should be mapped to the MariaDB user dba. (@dba: dba)

Creating Our Unix Users and Groups

Let's go ahead and create the Unix users and groups that we are using for this hypothetical scenario.

First, let's create the foo user and a couple users to go into the dba group. Note that each of these users needs a password.

Next, let's create the dba group and add our two users to it:

We also need to create Unix users with the same name as the bar and dba MariaDB users. See to read more about why. No one will be logging in as these users, so they do not need passwords.

Installing the pam_user_map PAM Module

Next, let's .

Before the module can be compiled from source, we may need to install some dependencies.

On RHEL, CentOS, and other similar Linux distributions that use , we need to install gcc and pam-devel:

On Debian, Ubuntu, and other similar Linux distributions that use , we need to install gcc and libpam0g-dev:

And then we can build and install the library with the following:

Configuring the pam_user_map PAM Module

Next, let's based on our hypothetical requirements.

The configuration file for the pam_user_map PAM module is /etc/security/user_map.conf. Based on our hypothetical requirements, ours would look like:

Installing the PAM Authentication Plugin

Next, let's .

Log into the MariaDB Server and execute the following:

Configuring the PAM Service

Next, let's . We will call our service mariadb, so our PAM service configuration file will be located at /etc/pam.d/mariadb on most systems.

Since we are only doing Unix authentication with the pam_unix PAM module and group mapping with the pam_user_map PAM module, our configuration file would look like this:

Configuring the pam_unix PAM Module

The pam_unix PAM module adds on a lot of systems. We basically have to give the user that runs mysqld access to /etc/shadow.

If the mysql user is running mysqld, then we can do that by executing the following:

The server needs to be restarted for this change to take affect.

Creating MariaDB Users

Next, let's . Remember that our PAM service is called mariadb.

First, let's create the MariaDB user for the user mapping: foo: bar . This means we need to create a bar user:

Next, let's create the MariaDB user for the group mapping: @dba: dba . This means that we need to create a dba user:

Next, to allow for the user and group mapping, we need to that is also able to PROXY as the bar and dba users. Before we can create the proxy user, we might need to :

Finally, let's create the anonymous proxy user:

Testing our Configuration

Next, let's test out our configuration by . We can verify this by logging in as each of our users and comparing the return value of , which is the original user name and the return value of , which is the authenticated user name.

First, let's test our foo user:

We can verify that our foo Unix user was properly mapped to the bar MariaDB user by looking at the return value of CURRENT_USER().

Next, let's test our alice user in the dba group:

Finally, let's test our bob user in the dba group:

We can verify that our alice and bob Unix users in the dba Unix group were properly mapped to the dba MariaDB user by looking at the return values of CURRENT_USER().

_{This page is licensed: CC BY-SA / Gnu FDL}

MySQL has used SHA-1 based authentication since version 4.1. The authentication plugin is called . Over the years as computers became faster, new attacks on SHA-1 were being developed. Nowadays SHA-1 is no longer considered as secure as it was in 2001. That's why the ed25519 authentication plugin was created.

The ed25519 authentication plugin uses to securely store users' passwords and to authenticate users. The algorithm is the same one that is . It is based on the elliptic curve and code created by .

Overview

Even when using the pam authentication plugin, the authenticating PAM user account still needs to exist in MariaDB, and the account needs to have privileges in the database. Creating these MariaDB accounts and making sure the privileges are correct can be a lot of work. To decrease the amount of work involved, some users would like to be able to map a PAM user to a different MariaDB user. For example, let’s say that alice and bob are both DBAs. It would be nice if each of them could log into MariaDB with their own PAM username and password, while MariaDB sees both of them as the same dba user. That way, there is only one MariaDB account to keep track of.

Although most PAM modules usually do not do things like this, PAM supports the ability to change the user name in the process of authentication.The MariaDB pam authentication plugin fully supports this feature of PAM.

The pam_user_map PAM Module

Rather than building user and group mapping into the pam authentication plugin, MariaDB thought that it would cover the most use cases and offer the most flexibility to offload this functionality to an external PAM module. The pam_user_map PAM module was implemented by MariaDB to facilitate this. This PAM module can be used by the pam authentication plugin, just like other PAM modules.

Lack of Support for MySQL/Percona Group Mapping Syntax

Unlike MariaDB, MySQL and Percona implemented group mapping in their PAM authentication plugins. If you've read through or , you've probably seen syntax where the group mappings are provided in the statement like this:

Since MariaDB's user and group mapping is performed by an external PAM module, MariaDB's pam authentication plugin does not support this syntax. Instead, the user and group mappings for the pam_user_map PAM module are configured in an external configuration file. This is discussed in a later section.

Installing the pam_user_map PAM Module

The pam_user_map PAM module gets installed as part of all our MariaDB server packages.

Some Linux distributions have not picked up this change in their own packages yet. When using such an installation, it may be necessary to compile the PAM module from source as described in the next section, or to manually extract it from one of our server packages and copy it to the target system.

Installing the pam_user_map PAM Module from Source

Installing Compilation Dependencies

Before the module can be compiled from source, you may need to install some dependencies.

On RHEL, CentOS, and other similar Linux distributions that use , you need to install gcc, pam-devel and MariaDB-devel:

On Debian, Ubuntu, and other similar Linux distributions that use , you need to install gcc, libpam0g-dev:

Compiling and Installing the pam_user_map PAM Module

The pam_user_map PAM module can be built by downloading plugin/auth_pam/mapper/pam_user_map.c file from the MariaDB source tree and compiling it after minor adjustments. Once it is built, it can be installed to the system's PAM module directory, which is typically /lib64/security/:

You also need to adjust the major version number in the URL on the first line to match your installed MariaDB version, and the #-I include path argument on the gcc line, as depending on operating system and MariaDB server version, the plugin_auth_common.h file may be installed in a directory other than /usr/include/mysql/ .

Configuring the pam_user_map PAM Module

The pam_user_map PAM module uses the configuration file at the path /etc/security/user_map.conf to determine its user and group mappings. The file's format is described below.

To map a specific PAM user to a specific MariaDB user:

Or to map any PAM user in a specific PAM group to a specific MariaDB user, the group name is prefixed with @:

For example, here is an example /etc/security/user_map.conf:

Configuring PAM

With user and group mapping, configuring PAM is done similar to how it is . However, when configuring the PAM service, you will have to add an auth line for the pam_user_map PAM module to the service's PAM configuration file:

Creating Users

With user and group mapping, creating users is done similar to how it is . However, one major difference is that you will need to the privilege on the mapped user to the original user.

Consider having the following configured in /etc/security/user_map.conf:

Then you could execute the following to grant the relevant privileges:

Note that the ''@'%' account is a special catch-all . Any login by a user that has no more specific account match in the system will be matched by this anonymous account.

Also note that you might not be able to create the ''@'%' anonymous account by default on some systems without doing some extra steps first. See for more information.

Verifying that Mapping is Occurring

In case any user mapping is performed, the original user name is returned by the SQL function , while the authenticated user name is returned by the SQL function . The latter actually defines what privileges are available to a connected user.

Consider having the following configured:

Then the following output would verify that it is working properly:

We can verify that our foo PAM user was properly mapped to the bar MariaDB user by looking at the return value of CURRENT_USER().

Logging

By default, the pam_user_map PAM module does not perform any logging. However, if you want to enable debug logging, then you can add the debug module argument to the service's PAM configuration file:

When debug logging is enabled, the pam_user_map PAM module will write log entries to the as other PAM modules, which is typically /var/log/secure on many systems.

For example, this debug log output can look like the following:

Known Issues

PAM User with Same Name as Mapped MariaDB User Must Exist

With user and group mapping, any PAM user or any PAM user in a given PAM group can be mapped to a specific MariaDB user account. However, due to the way PAM works, a PAM user with the same name as the mapped MariaDB user account must exist.

Consider the configuration file for the PAM service file containing the following:

Consider etc/security/user_map.conf containing the following:

In that case, any PAM user in the PAM group dba are mapped to the MariaDB user account dba. But if a PAM user with the name dba doesn't exist, the pam_user_map PAM module's debug logging writes errors to the syslog, like the following:

In the above log snippet, notice that both the pam_unix and the pam_sss PAM modules are complaining that the dba PAM user does not appear to exist, and that these complaints cause the PAM authentication process to fail, which causes the MariaDB authentication process to fail as well.

This can be fixed by creating a PAM user with the same name as the mapped MariaDB user account, which is dba in this case.

You may also be able to work around this problem by essentially disabling PAM's account verification for the service with the PAM module. For example, in the above case, that would be:

See for more information.

Tutorials

You may find the following PAM and user mapping-related tutorials helpful:

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

The unix_socket authentication plugin is installed by default, and it is used by the 'root'@'localhost' user account by default. See Authentication for more information.

The unix_socket authentication plugin allows the user to use operating system credentials when connecting to MariaDB via the local Unix socket file. This Unix socket file is defined by the socket system variable.

The unix_socket authentication plugin works by calling the getsockopt system call with the SO_PEERCRED socket option, which allows it to retrieve the uid of the process that is connected to the socket. It is then able to get the user name associated with that uid. Once it has the user name, it will authenticate the connecting user as the MariaDB account that has the same user name.

The unix_socket authentication plugin is not suited to multiple Unix users accessing a single MariaDB user account.

Security

A unix_socket authentication plugin is a passwordless security mechanism. Its security lies in the strength of the access to the Unix user, rather than the complexity and the secrecy of the password.

Strengths

• Access is limited to the Unix user so, for example, a www-data user cannot access root with the unix_socket authentication plugin.

• There is no password which can be cracked by brute force.

• There is no password that can be accidentally exposed by user accident, poor security on backups, or poor security on passwords in configuration files.

Weaknesses

The strength of a unix_socket authentication plugin is effectively the strength of the security of the Unix users on the system. In most cases, the Unix user default installation is sufficiently secure. However, the following is a non-exhaustive list of potential Unix user security issues that may arise.

• Common access areas without screen locks, where an unauthorized user accesses the logged in Unix user of an authorized user.

• Extensive sudo access grants that provide users with access to execute commands of a different Unix user.

• Scripts writable by Unix users other than the Unix user that are executed (via cron or directly) by the Unix user.

• Web pages that are susceptible to command injection, where the Unix user running the web page has elevated privileges in the database that weren't intended to be used.

In some of these scenarios a database password may prevent these security exploits, however it will remove all the strengths of the unix_socket authentication plugin previously mentioned.

Disabling the Plugin

The unix_socket authentication plugin is installed by default.

The unix_socket authentication plugin is also installed by default in new installations that use the packages provided by Debian's default repositories and Ubuntu's default repositories. See for more information.

The unix_socket authentication plugin can be disabled by starting the server with the option set to OFF. This can be specified as a command-line argument to or it can be specified in a relevant server in an :

As an alternative, the option can also be set to OFF by pairing the option with the disable :

Installing the Plugin

The unix_socket authentication plugin is installed by default in almost all MariaDB server versions. If you work with a version that doesn't have the plugin installed, you can install it as described in one of the following ways.

• Install the plugin without restarting the server. You can install the plugin dynamically, by executing or :

• Instruct the server to load the plugin at startup. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an :

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or :

If you installed the plugin by providing the or the options in a server in an , those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Creating Users

To create a user account via , specify the name of the plugin in the clause:

If does not have NO_AUTO_CREATE_USER set, then you can also create the user account via :

Switching to Password-Based Authentication

If Unix socket authentication does not meet your needs, you can switch a user account back to password-based authentication, by telling MariaDB to use a different for the account. The specific authentication plugin is specified with the clause. To switch to the authentication plugin, you need to do this:

Client Authentication Plugins

The unix_socket authentication plugin does not require any specific client authentication plugins. It should work with all clients.

Support in Client Libraries

The unix_socket authentication plugin does not require any special support in client libraries. It should work with all client libraries.

Example

In this example, user serg is already logged into the operating system and has full shell access. The user has already authenticated with the operating system and the MariaDB account is configured to use the unix_socket authentication plugin, so there is no need to authenticate again for the database. MariaDB accepts the operating system credentials and allows the user to connect. However, any attempt to connect to the database as another operating system is denied.

Options

unix_socket

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

cracklib_password_check is a password validation plugin. It uses the CrackLib library to check the strength of new passwords. CrackLib is installed by default in many Linux distributions, since the system's Pluggable Authentication Module (PAM) authentication framework is usually configured to check the strength of new passwords with the pam_cracklib PAM module.

Note that passwords can be directly set as a hash, bypassing the password validation, if the strict_password_validation variable is OFF (it is ON by default).

The plugin requires at least cracklib 2.9.0, so it is not available on Debian/Ubuntu builds before Debian 8 Jessie/Ubuntu 14.04 Trusty, RedHat Enterprise Linux / CentOS 6.

Installing the Plugin's Package

The cracklib_password_check plugin's shared library is included in MariaDB packages as the cracklib_password_check.so or cracklib_password_check.dll shared library on systems where it can be built.

Installing on Linux

The cracklib_password_check plugin is included in systemd on Linux, but not in the older generic and glibc_214 tarballs.

Installing with a Package Manager

The cracklib_password_check plugin can also be installed via a package manager on Linux. In order to do so, your system needs to be configured to install from one of the MariaDB repositories.

You can configure your package manager to install it from MariaDB Corporation's MariaDB Package Repository by using the .

You can also configure your package manager to install it from MariaDB Foundation's MariaDB Repository by using the .

Installing with yum/dnf

On RHEL, CentOS, Fedora, and other similar Linux distributions, it is highly recommended to install the relevant from MariaDB's repository using or . Starting with RHEL 8 and Fedora 22, yum has been replaced by dnf, which is the next major version of yum. However, yum commands still work on many systems that use dnf:

Installing with apt-get

On Debian, Ubuntu, and other similar Linux distributions, it is highly recommended to install the relevant from MariaDB's repository using :

Installing with zypper

On SLES, OpenSUSE, and other similar Linux distributions, it is highly recommended to install the relevant from MariaDB's repository using :

Installing the Plugin

Once the shared library is in place, the plugin is not actually installed by MariaDB by default. There are two methods that can be used to install the plugin with MariaDB.

The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing or :

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to mariadbd, or it can be specified in a relevant server in an :

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing or :

If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Viewing CrackLib Errors

If password validation fails, then the original CrackLib error message can be viewed by executing .

Example

When creating a new password, if the criteria are not met, the following error is returned:

Known Issues

SELinux

When using the standard policy with the set to enforcing, mariadbd does not have access to /usr/share/cracklib, and you may see the following error when attempting to use the cracklib_password_check plugin:

And the SELinux audit.log contains errors like these:

This can be fixed by creating an SELinux policy that allows mysqld to load the CrackLib dictionary:

See for more information.

System Variables

cracklib_password_check_dictionary

• Description: Sets the path to the CrackLib dictionary. If not set, the default CrackLib dictionary path is used. The parameter expects the base name of a cracklib dictionary (a set of three files with endings .hwm, .pwd, .pwi), not a directory path.

• Command line: --cracklib-password-check-dictionary=value

• Scope: Global

Options

cracklib_password_check

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

See Also

• - permits the setting of basic criteria for passwords

_{This page is licensed: CC BY-SA / Gnu FDL}

Logs can be written to a separate file or to the system logs. If you prefer to have the logging separated from other system information, the value of the variable server_audit_output_type should be set to file. Incidentally, file is the only option on Windows systems.

You can force a rotation by enabling the server_audit_file_rotate_now variable like so:

SET GLOBAL server_audit_file_rotate_now = ON;

Separate log files

In addition to setting server_audit_output_type, you will have to provide the file path and name of the audit file. This is set in the variable . You can set the file size limit of the log file with the variable

So, if rotation is on and the log file has reached the size limit you set, a copy is created with a consecutive number as extension the original file will be truncated to be used for the auditing again. To limit the number of log files created, set the variable You can force log file rotation by setting the variable to a value of ON. When the number of files permitted is reached, the oldest file will be overwritten. Here is how those variables might be set in a :

System logs

For security reasons, it's better sometimes to use the system logs instead of a local file owned by the mysql user. To do this, the value of needs to be set to syslog. Advanced configurations, such as using a remote syslogd service, are part of the syslogd configuration.

The variables, and can be used to identify a system log entry made by the audit plugin. If a remote syslogd service is used for several MariaDB servers, these same variables are also used to identify the MariaDB server.

Here is a system log entry taken from a server which had set to the default value of mysql­-server_auditing, and set to <prod1>.

Although the default values for and should be sufficient in most cases. They can be changed based on the definition in syslog.h for the functions openlog() and syslog().

_{This page is licensed: CC BY-SA / Gnu FDL}

Events that are logged by the MariaDB Audit Plugin are grouped generally into different types: connect, query, and table events. To log based on these types of events, set the variable, to CONNECT, QUERY, or TABLE. To have the Audit Plugin log more than one type of event, put them in a comma-separated list like so:

You can put the equivalent of this in the configuration file like so:

By default, logging is set to OFF. To enable it, set the variable to ON. Note that if the is enabled, and a query is returned from the query cache, no TABLE records will appear in the log since the server didn't open or access any tables and instead relied on the cached results. So you may want to disable query caching.

The feedback plugin is designed to collect and, optionally, upload configuration and usage information to or to any other configured URL.

See the page on MariaDB.org to see collected MariaDB usage statistics.

MariaDB is usually distributed with this plugin included, but it is not enabled by default. On Windows, this plugin is part of the server and has a special checkbox in the installer window. Either way, you need to explicitly install and enable it in order for feedback data to be sent.

Verifying the Plugin's Status