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:

• Installation

• Configuration

• Log Settings

• Log Location & Rotation

• Log Format

• Status Variables

• System Variables

Tutorials

• Activating MariaDB Audit Log by Jaykishan Mutkawoa, May 30, 2016

• Installing MariaDB Audit Plugin on Amazon RDS Amazon RDS supports using the MariaDB Audit Plugin on MySQL and MariaDB database instances.

Blog Posts

• MySQL Auditing with MariaDB Auditing Plugin by Peter Zaitsev, February 15, 2016

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 plugin_dir system variable. To see the value of this variable and thereby determine the file path of the plugin library, execute the following SQL statement:

SHOW GLOBAL VARIABLES LIKE 'plugin_dir';

+---------------+--------------------------+
| Variable_name | Value                    |
+---------------+--------------------------+
| plugin_dir    | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+

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 INSTALL SONAME or INSTALL PLUGIN:

INSTALL SONAME 'server_audit';

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 --plugin-load or the --plugin-load-add options. This can be specified as a command-line argument to mariadbd , or it can be specified in a relevant server option group in an option file:

[mariadb]
...
plugin_load_add = server_audit

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing UNINSTALL SONAME or UNINSTALL PLUGIN:

UNINSTALL SONAME 'server_audit';

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

Prohibiting Uninstallation

The UNINSTALL SONAME or UNINSTALL PLUGIN 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 server_audit option to FORCE_PLUS_PERMANENT in a relevant server option group in an option file after the plugin is loaded once:

[mariadb]
...
plugin_load_add = server_audit
server_audit=FORCE_PLUS_PERMANENT

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:

UNINSTALL PLUGIN server_audit;

ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloaded

For more information on FORCE_PLUS_PERMANENT and other option values for the server_audit option, see Plugin Overview: Configuring Plugin Activation at Server Startup for more information.

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

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 audit plugin-related variables on the server and their values, execute the follow while connected to the server:

SHOW GLOBAL VARIABLES LIKE 'server_audit%';

+-------------------------------+-----------------------+
| Variable_name                 | Value                 |
+-------------------------------+-----------------------+
| server_audit_events           | CONNECT,QUERY,TABLE   |
| server_audit_excl_users       |                       |
| server_audit_file_path        | server_audit.log      |
| server_audit_file_rotate_now  | OFF                   |
| server_audit_file_rotate_size | 1000000               |
| server_audit_file_rotations   | 9                     |
| server_audit_incl_users       |                       |
| server_audit_logging          | ON                    |
| server_audit_mode             | 0                     |
| server_audit_output_type      | file                  |
| server_audit_query_log_limit  | 1024                  |
| server_audit_syslog_facility  | LOG_USER              |
| server_audit_syslog_ident     | mysql-server_auditing |
| server_audit_syslog_info      |                       |
| server_audit_syslog_priority  | LOG_INFO              |
+-------------------------------+-----------------------+

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

SET GLOBAL server_audit_logging=OFF;

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., /etc/my.cnf.d/server.cnf) to ensure the values are the same after a restart:

[server]
... 
server_audit_logging=OFF 
…

For the reason given in the paragraph above, you would not generally set variables related to the auditing plugin using the SET statement. However, you might do so to test settings before making them more permanent. Since one cannot always restart the server, you would use the SET statement to change immediately the variables and then include the same settings in the configuration file so that the variables are set again as you prefer when the server is restarted.

Configuring Logs and Setting Other Variables

Of all of the server variables you can set, you may want to set initially the server_audit_events variable to tell the Audit Plugin which events to log. The Log Settings documentation page describes in detail the choices you have and provides examples of log entries related to them.

You can see a detailed list of system variables related to the MariaDB Audit Plugin on the System Variables documentation page. Status variables related to the Audit Plugin are listed and explained on the Status Variables documentation page.

_{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, server_audit_events 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:

SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';

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

[mysqld]
...
server_audit_events=connect,query

By default, logging is set to OFF. To enable it, set the server_audit_logging variable to ON. Note that if the query cache 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.

There are a few types of events that may be logged, not just the three common ones mentioned above. A full list of related system variables is detailed on the Server_Audit System Variables page, and status variables on the Server_Audit System Variables page of this documentation. Some of the major ones are highlighted below:

Since there are other types of queries besides DDL and DML, using the QUERY_DDL and QUERY_DML options together is not equivalent to using QUERY. There is the QUERY_DCL option for logging DCL types of queries (e.g., and GRANT``REVOKEstatements). In the same version, the server_audit_query_log_limit variable was added to be able to set the length of a log record. Previously, a log entry would be truncated due to long query strings.

Logging Connect Events

If the Audit Plugin has been configured to log connect events, it will log connects, disconnects, and failed connects. For a failed connection, the log includes the error code.

It's possible to define a list of users for which events can be excluded or included for tracing their database activities. This list will be ignored, though, for the logging of connect events. This is because auditing standards distinguish between technical and physical users. Connects need to be logged for all types of users; access to objects needs to be logged only for physical users.

Logging Query Events

If QUERY, QUERY_DDL, QUERY_DML, QUERY_DML_NO_SELECT, and/or QUERY_DCL event types are enabled, then the corresponding types of queries that are executed will be logged for defined users. The queries will be logged exactly as they are executed, in plain text. This is a security vulnerability: anyone who has access to the log files will be able to read the queries. So make sure that only trusted users have access to the log files and that the files are in a protected location. An alternative is to use the⁣TABLE event type instead of the query-related event types.

Queries are also logged if they cannot be executed or if they're unsuccessful. For example, a query will be logged because of a syntax error or because the user doesn't have the privileges necessary to access an object. These queries can be parsed by the error code that's provided in the log.

You may find failed queries to be more interesting: They can reveal problems with applications (e.g., an SQL statement in an application that doesn't match the current schema). They can also reveal if a malicious user is guessing at the names of tables and columns to try to get access to data.

Below is an example in which a user attempts to execute an UPDATE statement on a table for which he does not have permission:

UPDATE employees 
SET salary = salary * 1.2 
WHERE emp_id = 18236;

ERROR 1142 (42000): 
UPDATE command denied to user 'bob'@'localhost' for table 'employees'

Looking in the Audit Plugin log (server_audit.log) for this entry, you can see the following entry:

20170817 11:07:18,ip-172-30-0-38,bob,localhost,15,46,QUERY,company,
'UPDATE employees SET salary = salary * 1.2 WHERE emp_id = 18236',1142

This log entry would be on one line, but it's reformatted here for better rendering. Looking at this log entry, you can see the date and time of the query, followed by the server host and the user and host for the account. Next is the connection and query identification numbers (i.e., 15 and 46). After the log event type (i.e., QUERY), the database name (i.e., company), the query, and the error number are recorded.

Notice that the last value in the log entry is 1142. That's the error number for the query. To find failed queries, you would look for two elements: the notation indicating that it's an entry QUERY and the last value for the entry. If the query is successful, the value will be0 .

Queries Not Included in Subordinate Query Event Types

Note that the QUERY event type will log queries that are not included in any of the subordinate QUERY_* event types, such as:

• CREATE FUNCTION

• DROP FUNCTION

• CREATE PROCEDURE

• DROP PROCEDURE

• SET

• CHANGE MASTER TO

• FLUSH

• KILL

• CHECK

• OPTIMIZE

• LOCK

• UNLOCK

• ANALYZE

• INSTALL PLUGIN

• UNINSTALL PLUGIN

• INSTALL SONAME

• UNINSTALL SONAME

• EXPLAIN

Logging Table Events

MariaDB has the ability to record table events in the logs—this is not a feature of MySQL. This feature is the only way to log which tables have been accessed through a view, a stored procedure, a stored function, or a trigger. Without this feature, a log entry for a query shows only the view, stored procedure or function used, not the underlying tables. Of course, you could create a custom application to parse each query executed to find the SQL statements used and the tables accessed, but that would be a drain on system resources. Table event logging is much simpler: it adds a line to the log for each table accessed, without any parsing. It includes notes as to whether it was a read or a write.

If you want to monitor user access to specific databases or tables (e.g., mysql.user), you can search the log for them. Then if you want to see a query which accessed a certain table, the audit log entry will include the query identification number. You can use it to search the same log for the query entry. This can be useful when searching a log containing tens of thousands of entries.

Because of the TABLE option, you may disable query logging and still know who accessed which tables. You might want to disable QUERY event logging to prevent sensitive data from being logged. Since table event logging will log who accessed which table, you can still watch for malicious activities with the log. This is often enough to fulfill auditing requirements.

Below is an example with both TABLE and QUERY events logging. For this scenario, suppose there is a VIEW in which columns are selected from a few tables in a company database. The underlying tables are related to sensitive employee information, in particular salaries. Although we may have taken precautions to ensure that only certain user accounts have access to those tables, we will monitor the Audit Plugin logs for anyone who queries them—directly or indirectly through a view.

20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,employees,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,employees_salaries,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,ref_job_titles,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,org_departments,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,QUERY,company,
'SELECT * FROM employee_pay WHERE title LIKE \'%Executive%\'  OR title LIKE \'%Manager%\'',0

Although the user executed only one SELECT statement, there are multiple entries to the log: one for each table accessed and one entry for the query on the view, (i.e., employee_pay). We know primarily this is all for one query because they all have the same connection and query identification numbers (i.e., 29 and 913).

Logging User Activities

The Audit Plugin will log the database activities of all users, or only the users that you specify. A database activity is defined as a query event or a table event. Connect events are logged for all users.

You may specify users to include in the log with the server_audit_incl_users variable or exclude users with the server_audit_excl_users variable. This can be useful if you would like to log entries, but are not interested in entries from trusted applications and would like to exclude them from the logs.

You would typically use either the server_audit_incl_users variable or the server_audit_excl_users variable. You may, though, use both variables. If a username is inadvertently listed in both variables, database activities for that user will be logged because server_audit_incl_users takes priority.

Although MariaDB considers a user as the combination of the username and hostname, the Audit Plugin logs only based on the username. MariaDB uses both the username and hostname so as to grant privileges relevant to the location of the user. Privileges are not relevant though for tracing the access to database objects. The host name is still recorded in the log, but logging is not determined based on that information.

The following example shows how to add a new username to the server_audit_incl_users variable without removing previous usernames:

SET GLOBAL server_audit_incl_users = CONCAT(@@global.server_audit_incl_users, ',Maria');

Remember to add also any new users to be included in the logs to the same variable in MariaDB configuration file. Otherwise, when the server restarts it will discard the setting.

Excluding or Including Users

By default events from all users are logged, but certain users can be excluded from logging by using the server_audit_excl_users variable. For example, to exclude users valerianus and rocky from having their events logged:

server_audit_excl_users=valerianus,rocky

This option is primarily used to exclude the activities of trusted applications.

Alternatively, server_audit_incl_users can be used to specifically include users. Both variables can be used, but if a user appears on both lists, server_audit_incl_users has a higher priority, and their activities will be logged.

_{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 server_audit_file_path. You can set the file size limit of the log file with the variable server_audit_file_rotate_size.

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 server_audit_file_rotations. You can force log file rotation by setting the variable server_audit_file_rotate_now 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 server configuration file:

[mysqld]
...
server_audit_file_rotate_now=ON 
server_audit_file_rotate_size=1000000 
server_audit_file_rotations=5
...

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 server_audit_output_type needs to be set to syslog. Advanced configurations, such as using a remote syslogd service, are part of the syslogd configuration.

The variables, server_audit_syslog_ident and server_audit_syslog_info 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 server_audit_syslog_ident set to the default value of mysql­-server_auditing, and server_audit_syslog_info set to <prod1>.

Aug 717:19:58localhostmysql-­server_auditing: 
<prod1> localhost.localdomain,root,localhost,1,7, 
QUERY, mysql, 'SELECT * FROM user',0

Although the default values for server_audit_syslog_facility and server_audit_syslog_priority 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}

The audit plugin logs user access to MariaDB and its objects. The audit trail (i.e., 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:

[timestamp],[serverhost],[username],[host],[connectionid],
[queryid],[operation],[database],[object],[retcode]

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

[timestamp][syslog_host][syslog_ident]:[syslog_info][serverhost],[username],[host],
[connectionid],[queryid],[operation],[database],[object],[retcode]

Various events will result in different audit records. Some events will not return a value for some fields (e.g., 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.

[timestamp],[serverhost],[username],[host],[connectionid],0,CONNECT,[database],,0 
[timestamp],[serverhost],[username],[host],[connectionid],0,DISCONNECT,,,0 
[timestamp],[serverhost],[username],[host],[connectionid],0,FAILED_CONNECT,,,[retcode]

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

[timestamp],[serverhost],[username],[host],[connectionid],[queryid],QUERY,[database],[object], [retcode]

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

[timestamp],[serverhost],[username],[host],[connectionid],[queryid],CREATE,[database],[object], 
[timestamp],[serverhost],[username],[host],[connectionid],[queryid],READ,[database],[object], 
[timestamp],[serverhost],[username],[host],[connectionid],[queryid],WRITE,[database],[object], 
[timestamp],[serverhost],[username],[host],[connectionid],[queryid],ALTER,[database],[object], 
[timestamp],[serverhost],[username],[host],[connectionid],[queryid],RENAME,[database], 
[object_old]|[database_new].[object_new], 
[timestamp],[serverhost],[username],[host],[connectionid],[queryid],DROP,[database],[object],

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}

There are a several options and system variables related to the MariaDB Audit Plugin, once it has been installed. System variables can be displayed using the SHOW VARIABLES statement like so:

SHOW GLOBAL VARIABLES LIKE '%server_audit%';

+-------------------------------+-----------------------+
| Variable_name                 | Value                 |
+-------------------------------+-----------------------+
| server_audit_events           | CONNECT,QUERY,TABLE   |
| server_audit_excl_users       |                       |
| server_audit_file_path        | server_audit.log      |
| server_audit_file_rotate_now  | OFF                   |
| server_audit_file_rotate_size | 1000000               |
| server_audit_file_rotations   | 9                     |
| server_audit_incl_users       |                       |
| server_audit_logging          | ON                    |
| server_audit_mode             | 0                     |
| server_audit_output_type      | file                  |
| server_audit_query_log_limit  | 1024                  |
| server_audit_syslog_facility  | LOG_USER              |
| server_audit_syslog_ident     | mysql-server_auditing |
| server_audit_syslog_info      |                       |
| server_audit_syslog_priority  | LOG_INFO              |
+-------------------------------+-----------------------+

To change the value of one of these variables, you can use the SET statement, or set them at the command-line when starting MariaDB. It's recommended that you set them in the MariaDB configuration for the server like so:

[mariadb]
...
server_audit_excl_users='bob,ted'
...

System Variables

Below is a list of all system variables related to the Audit Plugin. See Server System Variables for a complete list of system variables and instructions on setting them. See also the full list of MariaDB options, system and status variables.

server_audit_events

• Description: If set, then this restricts audit logging to certain event types. If not set, then every event type is logged to the audit log: SET GLOBAL server_audit_events='connect, query'.

• Command line: --server-audit-events=value

• Scope: Global

• Dynamic: Yes

• Data Type: string

• Default Value: Empty string

• Valid Values:

  • CONNECT, QUERY, TABLE (MariaDB Audit Plugin < 1.2.0)

  • CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML (MariaDB Audit Plugin >= 1.2.0)

  • CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL (MariaDB Audit Plugin >=1.3.0)

  • CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL, QUERY_DML_NO_SELECT (MariaDB Audit Plugin >= 1.4.4)

  • See MariaDB Audit Plugin - Versions to determine which MariaDB releases contain each MariaDB Audit Plugin versions.

server_audit_excl_users

• Description: If not empty, it contains the list of users whose activity will NOT be logged: SET GLOBAL server_audit_excl_users='user_foo, user_bar'. CONNECT records aren't affected by this variable - they are always logged. The user is still logged if it's specified in server_audit_incl_users.

• Command line: --server-audit-excl-users=value

• Scope: Global

• Dynamic: Yes

• Data Type: string

• Default Value: Empty string

• Size limit: 1024 characters

server_audit_file_path

• Description: When server_audit_output_type=file, sets the path and the filename to the log file. If the specified path exists as a directory, then the log will be created inside that directory with the name 'server_audit.log'. Otherwise the value is treated as a filename. The default value is 'server_audit.log', which means this file will be created in the database directory.

• Command line: --server-audit-file-path=value

• Scope: Global

• Dynamic: Yes

• Data Type: string

• Default Value: server_audit.log

server_audit_file_rotate_now

• Description: When server_audit_output_type=file, the user can force the log file rotation by setting this variable to ON or 1.

• Command line: --server-audit-rotate-now[={0|1}]

• Scope: Global

• Dynamic: Yes

• Data Type: boolean

• Default Value: OFF

server_audit_file_rotate_size

• Description: When server_audit_output_type=file, it limits the size of the log file to the given amount of bytes. Reaching that limit turns on the rotation - the current log file is renamed as 'file_path.1'. The empty log file is created as 'file_path' to log into it. The default value is 1000000.

• Command line: --server-audit-rotate-size=#

• Scope: Global

• Dynamic: Yes

• Data Type: numeric

• Default Value: 1000000

• Range: 100 to 9223372036854775807

server_audit_file_rotations

• Description: When server_audit_output_type=file', this specifies the number of rotations to save. If set to 0 then the log never rotates. The default value is 9.

• Command line: --server-audit-rotations=#

• Scope: Global

• Dynamic: Yes

• Data Type: numeric

• Default Value: 9

• Range: 0 to 999

server_audit_incl_users

• Description: If not empty, it contains a comma-delimited list of users whose activity will be logged: SET GLOBAL server_audit_incl_users='user_foo, user_bar'. CONNECT records aren't affected by this variable - they are always logged. This setting has higher priority than server_audit_excl_users. So if the same user is specified both in incl_ and excl_ lists, they will still be logged.

• Command line: --server-audit-incl-users=value

• Scope: Global

• Dynamic: Yes

• Data Type: string

• Default Value: Empty string

• Size limit: 1024 characters

server_audit_loc_info

• Description: Used by plugin internals. It has no useful meaning to users.

  • In earlier versions, users see it as a read-only variable.

  • In later versions, it is hidden from the user.

• Command line: N/A

• Scope: Global

• Dynamic: No

• Data Type: string

• Default Value: Empty string

server_audit_logging

• Description: Enables/disables the logging. Expected values are ON/OFF: SET GLOBAL server_audit_logging=on If the server_audit_output_type is FILE, this will actually create/open the logfile so the server_audit_file_path should be properly specified beforehand. Same about the SYSLOG-related parameters. The logging is turned off by default.

• Command line: --server-audit-logging[={0|1}]

• Scope: Global

• Dynamic: Yes

• Data Type: boolean

• Default Value: OFF

server_audit_mode

• Description: This variable doesn't have any distinctive meaning for a user. Its value mostly reflects the server version with which the plugin was started and is intended to be used by developers for testing.

• Command line: --server-audit-mode[=#]

• Scope: Global

• Dynamic: Yes

• Data Type: numeric

• Default Value: 0

• Range: 0 to 1

server_audit_output_type

• Description: Specifies the desired output type. Can be SYSLOG, FILE or null as no output: SET GLOBAL server_audit_output_type=file file: log records will be saved into the rotating log file. The name of the file set by server_audit_file_path variable. syslog: log records will be sent to the local syslogd daemon with the standard <syslog.h> API. The default value is 'file'.

• Command line: --server-audit-output-type=value

• Scope: Global

• Dynamic: Yes

• Data Type: enum

• Default Value: file

• Valid Values: SYSLOG, FILE

server_audit_query_log_limit

• Description: Limit on the length of the query string in a record.

• Command line: --server-audit-query-log-limit=#

• Scope: Global

• Dynamic: Yes

• Data Type: numeric

• Default Value: 1024

• Range: 0 to 2147483647

server_audit_syslog_facility

• Description: SYSLOG-mode variable. It defines the 'facility' of the records that will be sent to the syslog. Later the log can be filtered by this parameter.

• Command line: --server-audit-syslog-facility=value

• Scope: Global

• Dynamic: Yes

• Data Type: enum

• Default Value: LOG_USER

• Valid Values: LOG_USER, LOG_MAIL, LOG_DAEMON, LOG_AUTH, LOG_SYSLOG, LOG_LPR, LOG_NEWS, LOG_UUCP, LOG_CRON, LOG_AUTHPRIV, LOG_FTP, and LOG_LOCAL0–LOG_LOCAL7.

server_audit_syslog_ident

• Description: SYSLOG-mode variable. String value for the 'ident' part of each syslog record. Default value is 'mysql-server_auditing'. New value becomes effective only after restarting the logging.

• Command line: --server-audit-syslog-ident=value

• Scope: Global

• Dynamic: Yes

• Data Type: string

• Default Value: mysql-server_auditing

server_audit_syslog_info

• Description: SYSLOG-mode variable. The 'info' string to be added to the syslog records. Can be changed any time.

• Command line: --server-audit-syslog-info=value

• Scope: Global

• Dynamic: Yes

• Data Type: string

• Default Value: Empty string

server_audit_syslog_priority

• Description: SYSLOG-mode variable. Defines the priority of the log records for the syslogd.

• Command line: --server-audit-syslog-priority=value

• Scope: Global

• Dynamic: Yes

• Data Type: enum

• Default Value: LOG_INFO

• Valid Values:LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG

Options

server_audit

• 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 mysql.plugins table.

    • ON - Enables the plugin. If the plugin cannot be initialized, then the server will still continue starting up, but the plugin will be disabled.

    • FORCE - Enables the plugin. If the plugin cannot be initialized, then the server will fail to start with an error.

    • FORCE_PLUS_PERMANENT - Enables the plugin. If the plugin cannot be initialized, then the server will fail to start with an error. In addition, the plugin cannot be uninstalled with UNINSTALL SONAME or UNINSTALL PLUGIN while the server is running.

  • See MariaDB Audit Plugin - Installation: Prohibiting Uninstallation for more information.

  • See Plugin Overview: Configuring Plugin Activation at Server Startup for more information.

• Command line: --server-audit=val

• Data Type: enumerated

• Default Value: ON

• Valid Values: OFF, ON, FORCE, FORCE_PLUS_PERMANENT

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

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

SHOW STATUS LIKE 'server_audit%';

+----------------------------+------------------+
| Variable_name              | Value            |
+----------------------------+------------------+
| Server_audit_active        | ON               |
| Server_audit_current_log   | server_audit.log |
| Server_audit_last_error    |                  |
| Server_audit_writes_failed | 0                |
+----------------------------+------------------+

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 Server Status Variables for a complete list of status variables that can be viewed with the SHOW STATUS statement. See also the Full list of MariaDB options, system and status variables.

Server_audit_active

• Description: If the auditing is actually working. It gets the ON value when the logging is successfully started. Then it can get the OFF value if the logging was stopped or log records can't be properly stored due to file or syslog errors.

• Data Type: boolean

Server_audit_current_log

• Description: The name of the logfile or the SYSLOG parameters that are in current use.

• Data Type: string

Server_audit_last_error

• Description: If something went wrong with the logging here you can see the message.

• Data Type: string

Server_audit_writes_failed

• Description: The number of log records since last logging-start that weren't properly stored because of errors of any kind. The global value can be flushed by FLUSH STATUS.

• Data Type: numeric

• Default Value: 0

_{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}

Release date: 7 Nov 2013

This is a Stable (GA) release. In general this means that there are no known serious bugs, except for those marked as feature requests, that no bugs were fixed since last release that caused a notable code changes, and that we believe the code is ready for general usage (based on bug inflow).

Bug Fixes

• MDEV-5243 Version 1.1.2 for MySQL not providing facility correctly

• MDEV-5145 Windows build fixed.

• MDEV-5145 Client errors disabled for Percona/Mysql.

• MDEV-4472 Wrong filename doens't stop the logging.

• MDEV-4472 Error message fixed. Empty values for server_audit_file_path treated as default value.

• MDEV-4472 Now it's possible to specify a catalog as server_audit_file_path. In this case the log name will be [server_audit_file_path]/server_audit.log

Added platform and database server support

• The MariaDB Audit Plugin is now supported on Windows 64-bit and Windows 32-bit.

• Now the Audit Plugin can be used with Percona Server + Galera, i.e. the Percona XtraDB Cluster.

MariaDB Audit Plugin 1.1.3 Changelog

The revision number links will take you to the revision's page on Launchpad. On Launchpad you can view more details of the revision and view diffs of the code modified in that revision.

• Revision 3905, 2013-11-05

  • MDEV-5243 MariaDB Audit Plugin 1.1.2 for MySQL not providing facility correctly.

• Revision 3904, 2013-11-03

  • MDEV-5145 Audit plugin crashes on PXC when selecting file as output type. Windows build fixed.

• Revision 3903, 2013-10-28

  • MDEV-5145 Audit plugin crashes on PXC when selecting file as output type. Client errors disabled for Percona/Mysql.

• Revision 3902, 2013-10-26

  • Merging into 5.5-noga-hf.

• Revision 3901, 2013-09-27

  • MDEV-4472 Audit plugin. Fixed so the wrong filename doens't stop the logging.

• Revision 3900, 2013-09-27

  • MDEV-4472 Audit plugin. Error message fixed. Empty values for server_audit_file_path treated as default value.

• Revision 3899, 2013-09-27

  • MDEV-4472 Audit plugin. Now it's possible to specify a catalog as server_audit_file_path. In this case the log name will be [server_audit_file_path]/server_audit.log

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

Release date: 21 Feb 2014

This is a Stable (GA) release. In general this means that there are no known serious bugs, except for those marked as feature requests, that no bugs were fixed since last release that caused a notable code changes, and that we believe the code is ready for general usage (based on bug inflow).

Important Notices

• MariaDB will include the Audit Plugin by default from versions 5.5.37 and 10.0.10. At the time of writing these versions haven't yet been released.

• The MariaDB Audit Plugin works for MariaDB, MySQL and Percona Server.

Download

If you want to download the MariaDB Audit Plugin separately from the MariaDB server, it happens on SkySQL's site.

Main Improvements

• When a MariaDB Audit Plugin variable (e.g. server_audit_file_path) is changed the last query ("SET ..") will be added to the log before the new settings apply. With this, switching off auditing will also be audited.

• Warnings about missing table events when query cache is disabled has been added.

• Handling of server_audit_excl_users and incl_users. Users cannot be added to both lists. If a user is added to a excl list and already is in the incl list, the user is not included to the excl list and an error is given. If a user is added to the incl list, that already is in the excl list, the user is removed from the excl list and added to incl and a warning is given.

Added platform and database server support

• The Audit Plugin is now supported in MariaDB 10.0 and as said above it will be included by default into MariaDB 10.0, starting from version 10.0.9

• Previous versions of the Audit Plugin couldn't be used with Percona Server, but now support for that has been added.

Bug Fixes

• MDEV-4472 Fix for threadpool notifications of thread connects/disconnects

• MDEV-5693 ps-protocol mode caused a Audit Plugin test case failure

• MDEV-4472 Fix for Percona Server

• MDEV-4472 Fixes to usage of exc-users and incl-users

• MDEV-5365 Fixed issue with server_audit_excl_users and server_audit_incl_users in SHOW VARIABLES

• MDEV-4472 _my_hash_init in 10.0 fix.

MariaDB Audit Plugin 1.1.4 Changelog

The issue number links will take you to the corresponding issue in MariaDB project tracking.

• Revision 3912, 2014-02-17

  • MDEV-4472 server_audit.opt added. A temporary solution for Threadpool. Currently it doesn't notify plugins properly about thread connects/disconnects.

• Revision 3911, 2014-02-17

  • MDEV-5693 server_audit.test fails in --ps-protocol mode. Notifying from the mysqld_stmt_prepare/mysqld_stmt_execute has it's specifics. The command in this case is 'Prepare' and 'Execute' (not just 'Query'). When error is notified from the mysqld_stmt_prepare, the query string is empty. Fixed by tacking it all into account.

• Revision: 3910, 2014-02-14

  • MDEV-4472 Fix for Percona Server.

• Revision: 3909, 2014-01-30

  • MDEV-4472 Fixes to make the exc-users and incl-users work more smoothly.

• Revision: 3908, 2013-11-30

  • MDEV-5365 server_audit_excl_users and server_audit_incl_users behave weird when assigned. As these variables used same temporary buffer, the same content was shown to SHOW VARIABLES. Fixed by using separate buffers. Also warning added when the QUERY CACHE is active that TABLE events can be hidden by it.

• Revision: 3907, 2013-11-15

  • MDEV-4472 Version number set to 1.1.4. Additions 17.

• Revision: 3906, 2013-11-14

  • MDEV-4472 _my_hash_init in 10.0 fix.

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

Release date: 25 Feb 2014

This is a Stable (GA) release. In general this means that there are no known serious bugs, except for those marked as feature requests, that no bugs were fixed since last release that caused a notable code changes, and that we believe the code is ready for general usage (based on bug inflow).

Important Notices

• MariaDB will include the Audit Plugin by default from versions 5.5.37 and 10.0.10. At the time of writing these versions haven't yet been released.

• The MariaDB Audit Plugin works for MariaDB, MySQL and Percona Server.

Download

If you want to download the MariaDB Audit Plugin separately from the MariaDB server, it is available at SkySQL's site.

Main Improvements

• This version includes only one bug fix, but an important one without which crashes can occur with version 1.1.4 of the Audit Plugin. See below for more details and look at mariadb-audit-plugin-114-release-notes for other recent changes in the Audit Plugin.

Bug Fixes

• MDEV-5722 MariaDB audit plugin crashes when MariaDB Audit Plugin variables are set in my.cnf.

MariaDB Audit Plugin 1.1.5 Changelog

The issue number links will take you to the corresponding issue in MariaDB project tracking.

• Revision 3914, 2014-02-24

  • MDEV-5722 MariaDB audit plugin crashes when variables set in .my.cnf. The 'thd' parameter is NULL when variables are changed in server_audit_init(). That we should take into account.

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

Release date: 27 Mar 2014

This is a Stable (GA) release. In general this means that there are no known serious bugs, except for those marked as feature requests, that no bugs were fixed since last release that caused a notable code changes, and that we believe the code is ready for general usage (based on bug inflow).

Important Notices

• MariaDB will include the Audit Plugin by default from versions 5.5.37 and 10.0.10. At the time of writing these versions haven't yet been released.

• The MariaDB Audit Plugin works for MariaDB, MySQL and Percona Server.

Download

If you want to download the MariaDB Audit Plugin separately from the MariaDB server, it is available at SkySQL's site.

Bug Fixes

• MDEV-5681 audit log will not rotate when the file size exceeds global variable setting. The variables server_audit_file_rotate_now and server_audit_file_rotations are now handled and one doesn't need to stop/start logging to make them effective.

• MDEV-5862 server_audit test fails in buildbot on Mac (labrador). The RTLD_DEFAULT value on Labrador machine is not NULL, so the dlsym() commands in the server_audit just fail to bind the necessary functions. Fixed by using RTLD_DEFAULT explicitly.

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

Release date: 1 May 2014

This is a Stable (GA) release. In general this means that there are no known serious bugs, except for those marked as feature requests, that no bugs were fixed since last release that caused a notable code changes, and that we believe the code is ready for general usage (based on bug inflow).

Important Notices

• The Audit Plugin is included by default from versions 5.5.37 and 10.0.10.

• The MariaDB Audit Plugin works for MariaDB, MySQL and Percona Server. For MySQL and Percona Server it has to be downloaded separately from SkySQL's site

Download

If you want to download the MariaDB Audit Plugin separately from the MariaDB server, it is available at SkySQL's site.

Bug Fixes

• MDEV-6124 Audit plugin fails with the Percona-Server 5.6.

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