
| MAX_USER_CONNECTIONS                 | Number of simultaneous connections   |
|                                      | that can be accepted from the same   |
|                                      | account; if it is 0,                 |
|                                      | max_connections will be used         |
|                                      | instead; if max_connections is 0,    |
|                                      | there is no limit for this           |
|                                      | account's simultaneous connections.  |
+--------------------------------------+--------------------------------------+
| MAX_STATEMENT_TIME                   | Timeout, in seconds, for statements  |
|                                      | executed by the user. See also       |
|                                      | Aborting Statements that Exceed a    |
|                                      | Certain Time to Execute.             |
+--------------------------------------+--------------------------------------+

If any of these limits are set to 0, then there is no limit for that resource
for that user.

To set resource limits for an account, if you do not want to change that
account's privileges, you can issue a GRANT statement with the USAGE
privilege, which has no meaning. The statement can name some or all limit
types, in any order.

Here is an example showing how to set resource limits:

GRANT USAGE ON *.* TO 'someone'@'localhost' WITH
  MAX_USER_CONNECTIONS 0
  MAX_QUERIES_PER_HOUR 200;

The resources are tracked per account, which means 'user'@'server'; not per
user name or per connection.

The count can be reset for all users using FLUSH USER_RESOURCES, FLUSH
PRIVILEGES or mysqladmin reload.

Users with the CONNECTION ADMIN privilege (in MariaDB 10.5.2 and later) or the
SUPER privilege are not restricted by max_user_connections, max_connections,
or max_password_errors.

Per account resource limits are stored in the user table, in the mysql
database. Columns used for resources limits are named max_questions,
max_updates, max_connections (for MAX_CONNECTIONS_PER_HOUR), and
max_user_connections (for MAX_USER_CONNECTIONS).

TLS Options
-----------

By default, MariaDB transmits data between the server and clients without
encrypting it. This is generally acceptable when the server and client run on
the same host or in networks where security is guaranteed through other means.
However, in cases where the server and client exist on separate networks or
they are in a high-risk network, the lack of encryption does introduce
security concerns as a malicious actor could potentially eavesdrop on the
traffic as it is sent over the network between them.

To mitigate this concern, MariaDB allows you to encrypt data in transit
between the server and clients using the Transport Layer Security (TLS)
protocol. TLS was formerly known as Secure Socket Layer (SSL), but strictly
speaking the SSL protocol is a predecessor to TLS and, that version of the
protocol is now considered insecure. The documentation still uses the term SSL
often and for compatibility reasons TLS-related server system and status
variables still use the prefix ssl_, but internally, MariaDB only supports its
secure successors.

See Secure Connections Overview for more information about how to determine
whether your MariaDB server has TLS support.

You can set certain TLS-related restrictions for specific user accounts. For
instance, you might use this with user accounts that require access to
sensitive data while sending it across networks that you do not control. These
restrictions can be enabled for a user account with the CREATE USER, ALTER
USER, or GRANT statements. The following options are available:

+---------------------------+------------------------------------------------+
| Option                    | Description                                    |
+---------------------------+------------------------------------------------+
| REQUIRE NONE              | TLS is not required for this account, but can  |
|                           | still be used.                                 |
+---------------------------+------------------------------------------------+
| REQUIRE SSL               | The account must use TLS, but no valid X509    |
|                           | certificate is required. This option cannot    |
|                           | be combined with other TLS options.            |
+---------------------------+------------------------------------------------+
| REQUIRE X509              | The account must use TLS and must have a       |
|                           | valid X509 certificate. This option implies    |
|                           | REQUIRE SSL. This option cannot be combined    |
|                           | with other TLS options.                        |
+---------------------------+------------------------------------------------+
| REQUIRE ISSUER 'issuer'   | The account must use TLS and must have a       |
|                           | valid X509 certificate. Also, the Certificate  |
|                           | Authority must be the one specified via the    |
|                           | string issuer. This option implies REQUIRE     |
|                           | X509. This option can be combined with the     |
|                           | SUBJECT, and CIPHER options in any order.      |
+---------------------------+------------------------------------------------+