GRANT

Privileges

Syntax

GRANT
    priv_type [(column_list)]
      [, priv_type [(column_list)]] ...
    ON [object_type] priv_level
    TO user  [IDENTIFIED [BY [PASSWORD] 'password']
        |{VIA|WITH} plugin_name 
           [{USING|AS} 'plugin_option']]
        [, user [IDENTIFIED [BY [PASSWORD] 'password']
        |{VIA|WITH} plugin_name] 
           [{USING|AS} 'plugin_option']]
    user_options...

GRANT PROXY ON user_specification
    TO user_specification [, user_specification] ...
    [WITH GRANT OPTION]

user_options:
    [REQUIRE {NONE | tls_option [[AND] tls_option] ...}]
    [WITH with_option [with_option] ...]

object_type:
    TABLE
  | FUNCTION
  | PROCEDURE

priv_level:
    *
  | *.*
  | db_name.*
  | db_name.tbl_name
  | tbl_name
  | db_name.routine_name

with_option:
    GRANT OPTION
  | MAX_QUERIES_PER_HOUR count
  | MAX_UPDATES_PER_HOUR count
  | MAX_CONNECTIONS_PER_HOUR count
  | MAX_USER_CONNECTIONS count

tls_option:
    SSL
  | X509
  | CIPHER 'cipher'
  | ISSUER 'issuer'
  | SUBJECT 'subject'

Description

The GRANT statement allows you to create MariaDB user accounts and to grant privileges (or roles - see section below) to accounts. To use GRANT, you must have the GRANT OPTION privilege, and you must have the privileges that you are granting.

If the NO_AUTO_CREATE_USER SQL_MODE is set, users can only be created with a CREATE USER statement. In this case GRANT will produce an error when the specified user does not exist.

The user argument and the IDENTIFIED BY clause are the same as for the CREATE USER statement. If the user account does not yet exist, it will be implicitly created. You must have the privileges needed for the CREATE USER statement to implicitly create a user with GRANT. If the user account does exist and you provide the IDENTIFIED BY clause, the user's password will be changed. By specifying the IDENTIFIED VIA|WITH clause, the existing user account's password will be be set using the specified plugin. Some plugins require a plugin_option. You must have the privileges needed for the SET PASSWORD statement to change a user's password with GRANT.

Use the REVOKE statement to revoke privileges granted with the GRANT statement.

Use the SHOW GRANTS statement to determine what privileges an account has.

Privilege Levels

Privileges can be set globally, for an entire database, for a table or routine, or for individual columns in a table. Certain privileges can only be set at certain levels.

• Global privileges are granted using *.* for priv_level. Global privileges include privileges to administer the database and manage user accounts, as well as privileges for all tables, functions, and procedures. Global privileges are stored in the mysql.user table.
• Database privileges are granted using db_name.* for priv_level, or using just * to use default database. Database privileges include privileges to create tables and functions, as well as privileges for all tables, functions, and procedures in the database. Database privileges are stored in the mysql.db table.
• Table privileges are granted using db_name.tbl_name for priv_level, or using just tbl_name to specify a table in the default database. The TABLE keyword is optional. Table privileges include the ability to select and change data in the table. Certain table privileges can be granted for individual columns.
• Column privileges are granted by specifying a table for priv_level and providing a column list after the privilege type. They allow you to control exactly which columns in a table users can select and change.
• Function privileges are granted using FUNCTION db_name.routine_name for priv_level, or using just FUNCTION routine_name to specify a function in the default database.
• Procedure privileges are granted using PROCEDURE db_name.routine_name for priv_level, or using just PROCEDURE routine_name to specify a procedure in the default database.

The USAGE Privilege

The USAGE privilege grants no real privileges. The SHOW GRANTS statement will show a global USAGE privilege for a newly-created user. You can use USAGE with the GRANT statement to change options like GRANT OPTION and MAX_USER_CONNECTIONS without changing any account privileges.

The ALL PRIVILEGES Privilege

The ALL PRIVILEGES privilege grants all available privileges. Granting all privileges only affects the given privilege level. For example, granting all privileges on a table does not grant any privileges on the database or globally.

Using ALL PRIVILEGES does not grant the special GRANT OPTION privilege.

You can use ALL instead of ALL PRIVILEGES.

The GRANT OPTION Privilege

Use the WITH GRANT OPTION clause to give users the ability to grant privileges to other users at the given privilege level. Users with the GRANT OPTION privilege can only grant privileges they have. They cannot grant privileges at a higher privilege level than they have the GRANT OPTION privilege.

The GRANT OPTION privilege cannot be set for individual columns. If you use WITH GRANT OPTION when specifying column privileges, the GRANT OPTION privilege will be granted for the entire table.

Using the WITH GRANT OPTION clause is equivalent to listing GRANT OPTION as a privilege.

Global Privileges

The following table lists the privileges that can be granted globally. You can also grant all database, table, and function privileges globally. When granted globally, these privileges apply to all databases, tables, or functions, including those created later.

To set a global privilege, use *.* for priv_level.

Database Privileges

The following table lists the privileges that can be granted at the database level. You can also grant all table and function privileges at the database level. Table and function privileges on a database apply to all tables or functions in that database, including those created later.

To set a privilege for a database, specify the database using db_name.* for priv_level, or just use * to specify the default database.

Table Privileges

Column Privileges

Some table privileges can be set for individual columns of a table. To use column privileges, specify the table explicitly and provide a list of column names after the privilege type. For example, the following statement would allow the user to read the names and positions of employees, but not other information from the same table, such as salaries.

GRANT SELECT (name, position) on Employee to 'jeffrey'@'localhost';

Function Privileges

Procedure Privileges

Proxy Privileges

For example:

GRANT PROXY ON 'marijana'@'somehost' TO 'barrfhionn'@'somehost';

Setting per-account resources limits

It is possible to set a per-accout limit for the server resources that can be used. The following table shows the values that can be set per account:

If value of 0 is set for any of these limits, the limit is removed.

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 more than one limits:

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

The use of resource count is made per account, which means 'user'@'server'; not per user or per connection.

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

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).

Per-Account SSL/TLS Options

By default, MariaDB uses unencrypted connections for all client/server communications. In order to use encrypted connections, OpenSSL or yaSSL must be present in your system. Also, the MariaDB server needs to be built with TLS support and be properly configured to use one of them. See Secure Connections Overview for more. The term SSL, although referring to the old, now insecure, protocol preceding TLS, is still used in many of the variable names and options for compatibility reasons although MariaDB only uses its more secure successors.

You can require TLS connections on a per-account basis, using the REQUIRE clause. The following options are available:

If you require a X509 certificate, REQUIRE SSL is implicit. The ISSUER, SUBJECT, and CIPHER options can be combined together in any order, and if you use any of them REQUIRE X509 is implicit.

The REQUIRE keyword must be used only once for all specified options, and the AND keyword can be used to separate individual options (at your choice).

Here is an example:

GRANT USAGE ON *.* TO 'someone'@'localhost'
    REQUIRE SUBJECT '/CN=www.mydom.com/O=My Dom, Inc./C=US/ST=Oregon/L=Portland'
    AND ISSUER '/C=FI/ST=Somewhere/L=City/ O=Some Company/CN=Peter Parker/[email protected]'
    AND CIPHER 'SHA-DES-CBC3-EDH-RSA';

Examples

Creating a new user who can do anything (like root):

CREATE USER 'alexander'@'localhost';
GRANT ALL PRIVILEGES ON  *.* to 'alexander'@'localhost' WITH GRANT OPTION;

Roles

Syntax

GRANT role TO grantee [, grantee2 ... ]
[ WITH ADMIN OPTION ]

The GRANT statement is also used to grant the use of one or more roles to one or more users. In order to be able to grant a role, the grantor doing so must have permission to do so (see WITH ADMIN in the CREATE ROLE article).

Specifying the WITH ADMIN OPTION permits the grantee to in turn grant the role to another.

If a user has been granted a role, they do not automatically obtain all permissions associated with that role. These permissions are only in use when the user activates the role with the SET ROLE statement.

Examples

GRANT journalist TO hulda;

GRANT journalist TO berengar WITH ADMIN OPTION;

See also

• --skip-grant-tables allows you to start MariaDB without GRANT. This is useful if you lost your root password.
• Password Validation
• cracklib_password_check plugin - use the Cracklib password-strength checking library
• simple_password_check plugin - permits the setting of basic criteria for passwords