### 6.2.11 Account Categories

[]()[]()[]()[]()[]()

 As of MySQL 8.0.16, MySQL incorporates the concept of user account categories, based on the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege.

* [System and Regular Accounts](account-categories.html#system-user-accounts)

* [Operations Affected by the SYSTEM\_USER Privilege](account-categories.html#system-user-operations)

* [System and Regular Sessions](account-categories.html#system-user-sessions)

* [Protecting System Accounts Against Manipulation by Regular Accounts](account-categories.html#protecting-system-accounts)

#### System and Regular Accounts

 MySQL incorporates the concept of user account categories, with system and regular users distinguished according to whether they have the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege:

* A user with the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege is a system user.

* A user without the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege is a regular user.

 The [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege has an effect on the accounts to which a given user can apply its other privileges, as well as whether the user is protected from other accounts:

* A system user can modify both system and regular accounts. That is, a user who has the appropriate privileges to perform a given operation on regular accounts is enabled by possession of [`SYSTEM_USER`](privileges-provided.html#priv_system-user) to also perform the operation on system accounts. A system account can be modified only by system users with appropriate privileges, not by regular users.

* A regular user with appropriate privileges can modify regular accounts, but not system accounts. A regular account can be modified by both system and regular users with appropriate privileges.

 If a user has the appropriate privileges to perform a given operation on regular accounts, [`SYSTEM_USER`](privileges-provided.html#priv_system-user) enables the user to also perform the operation on system accounts. [`SYSTEM_USER`](privileges-provided.html#priv_system-user) does not imply any other privilege, so the ability to perform a given account operation remains predicated on possession of any other required privileges. For example, if a user can grant the [`SELECT`](privileges-provided.html#priv_select) and [`UPDATE`](privileges-provided.html#priv_update) privileges to regular accounts, then with [`SYSTEM_USER`](privileges-provided.html#priv_system-user) the user can also grant [`SELECT`](privileges-provided.html#priv_select) and [`UPDATE`](privileges-provided.html#priv_update) to system accounts.

 The distinction between system and regular accounts enables better control over certain account administration issues by protecting accounts that have the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege from accounts that do not have the privilege. For example, the [`CREATE USER`](privileges-provided.html#priv_create-user) privilege enables not only creation of new accounts, but modification and removal of existing accounts. Without the system user concept, a user who has the [`CREATE USER`](privileges-provided.html#priv_create-user) privilege can modify or drop any existing account, including the `root` account. The concept of system user enables restricting modifications to the `root` account (itself a system account) so they can be made only by system users. Regular users with the [`CREATE USER`](privileges-provided.html#priv_create-user) privilege can still modify or drop existing accounts, but only regular accounts.

#### Operations Affected by the SYSTEM\_USER Privilege

 The [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege affects these operations:

* Account manipulation.

   Account manipulation includes creating and dropping accounts, granting and revoking privileges, changing account authentication characteristics such as credentials or authentication plugin, and changing other account characteristics such as password expiration policy.

   The [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege is required to manipulate system accounts using account-management statements such as [`CREATE USER`](create-user.html) and [`GRANT`](grant.html). To prevent an account from modifying system accounts this way, make it a regular account by not granting it the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege. (However, to fully protect system accounts against regular accounts, you must also withhold modification privileges for the `mysql` system schema from regular accounts. See [Protecting System Accounts Against Manipulation by Regular Accounts](account-categories.html#protecting-system-accounts).)

* Killing current sessions and statements executing within them.

   To kill a session or statement that is executing with the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, your own session must have the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, in addition to any other required privilege ([`CONNECTION_ADMIN`](privileges-provided.html#priv_connection-admin) or the deprecated [`SUPER`](privileges-provided.html#priv_super) privilege).

   Prior to MySQL 8.0.16, [`CONNECTION_ADMIN`](privileges-provided.html#priv_connection-admin) privilege (or the deprecated [`SUPER`](privileges-provided.html#priv_super) privilege) is sufficient to kill any session or statement.

* Setting the `DEFINER` attribute for stored objects.

   To set the `DEFINER` attribute for a stored object to an account that has the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, you must have the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, in addition to any other required privilege ([`SET_USER_ID`](privileges-provided.html#priv_set-user-id) or the deprecated [`SUPER`](privileges-provided.html#priv_super) privilege).

   Prior to MySQL 8.0.16, the [`SET_USER_ID`](privileges-provided.html#priv_set-user-id) privilege (or the deprecated [`SUPER`](privileges-provided.html#priv_super) privilege) is sufficient to specify any `DEFINER` value for stored objects.

* Specifying mandatory roles.

   A role that has the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege cannot be listed in the value of the [`mandatory_roles`](server-system-variables.html#sysvar_mandatory_roles) system variable.

   Prior to MySQL 8.0.16, any role can be listed in [`mandatory_roles`](server-system-variables.html#sysvar_mandatory_roles).

* Overriding “abort” items in MySQL Enterprise Audit’s audit log filter.

   From MySQL 8.0.28, accounts with the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege are automatically assigned the [`AUDIT_ABORT_EXEMPT`](privileges-provided.html#priv_audit-abort-exempt) privilege, so that queries from the account are always executed even if an “abort” item in the audit log filter would block them. Accounts with the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege can therefore be used to regain access to a system following an audit misconfiguration. See [Section 6.4.5, “MySQL Enterprise Audit”](audit-log.html).

#### System and Regular Sessions

[]()[]()[]()

 Sessions executing within the server are distinguished as system or regular sessions, similar to the distinction between system and regular users:

* A session that possesses the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege is a system session.

* A session that does not possess the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege is a regular session.

 A regular session is able to perform only operations permitted to regular users. A system session is additionally able to perform operations permitted only to system users.

 The privileges possessed by a session are those granted directly to its underlying account, plus those granted to all roles currently active within the session. Thus, a session may be a system session because its account has been granted the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege directly, or because the session has activated a role that has the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege. Roles granted to an account that are not active within the session do not affect session privileges.

 Because activating and deactivating roles can change the privileges possessed by sessions, a session may change from a regular session to a system session or vice versa. If a session activates or deactivates a role that has the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, the appropriate change between regular and system session takes place immediately, for that session only:

* If a regular session activates a role with the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, the session becomes a system session.

* If a system session deactivates a role with the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, the session becomes a regular session, unless some other role with the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege remains active.

 These operations have no effect on existing sessions:

* If the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege is granted to or revoked from an account, existing sessions for the account do not change between regular and system sessions. The grant or revoke operation affects only sessions for subsequent connections by the account.

* Statements executed by a stored object invoked within a session execute with the system or regular status of the parent session, even if the object `DEFINER` attribute names a system account.

 Because role activation affects only sessions and not accounts, granting a role that has the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege to a regular account does not protect that account against regular users. The role protects only sessions for the account in which the role has been activated, and protects the session only against being killed by regular sessions.

#### Protecting System Accounts Against Manipulation by Regular Accounts

 Account manipulation includes creating and dropping accounts, granting and revoking privileges, changing account authentication characteristics such as credentials or authentication plugin, and changing other account characteristics such as password expiration policy.

 Account manipulation can be done two ways:

* By using account-management statements such as [`CREATE USER`](create-user.html) and [`GRANT`](grant.html). This is the preferred method.

* By direct grant-table modification using statements such as [`INSERT`](insert.html) and [`UPDATE`](update.html). This method is discouraged but possible for users with the appropriate privileges on the `mysql` system schema that contains the grant tables.

 To fully protect system accounts against modification by a given account, make it a regular account and do not grant it modification privileges for the `mysql` schema:

* The [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege is required to manipulate system accounts using account-management statements. To prevent an account from modifying system accounts this way, make it a regular account by not granting [`SYSTEM_USER`](privileges-provided.html#priv_system-user) to it. This includes not granting [`SYSTEM_USER`](privileges-provided.html#priv_system-user) to any roles granted to the account.

* Privileges for the `mysql` schema enable manipulation of system accounts through direct modification of the grant tables, even if the modifying account is a regular account. To restrict unauthorized direct modification of system accounts by a regular account, do not grant modification privileges for the `mysql` schema to the account (or any roles granted to the account). If a regular account must have global privileges that apply to all schemas, `mysql` schema modifications can be prevented using privilege restrictions imposed using partial revokes. See [Section 6.2.12, “Privilege Restriction Using Partial Revokes”](partial-revokes.html).

Note

 Unlike withholding the [`SYSTEM_USER`](privileges-provided.html#priv_system-user) privilege, which prevents an account from modifying system accounts but not regular accounts, withholding `mysql` schema privileges prevents an account from modifying system accounts as well as regular accounts. This should not be an issue because, as mentioned, direct grant-table modification is discouraged.

 Suppose that you want to create a user `u1` who has all privileges on all schemas, except that `u1` should be a regular user without the ability to modify system accounts. Assuming that the [`partial_revokes`](server-system-variables.html#sysvar_partial_revokes) system variable is enabled, configure `u1` as follows:

```
CREATE USER u1 IDENTIFIED BY 'password';

GRANT ALL ON *.* TO u1 WITH GRANT OPTION;
-- GRANT ALL includes SYSTEM_USER, so at this point
-- u1 can manipulate system or regular accounts

REVOKE SYSTEM_USER ON *.* FROM u1;
-- Revoking SYSTEM_USER makes u1 a regular user;
-- now u1 can use account-management statements
-- to manipulate only regular accounts

REVOKE ALL ON mysql.* FROM u1;
-- This partial revoke prevents u1 from directly
-- modifying grant tables to manipulate accounts
```

 To prevent all `mysql` system schema access by an account, revoke all its privileges on the `mysql` schema, as just shown. It is also possible to permit partial `mysql` schema access, such as read-only access. The following example creates an account that has `SELECT`, `INSERT`, `UPDATE`, and `DELETE` privileges globally for all schemas, but only `SELECT` for the `mysql` schema:

```
CREATE USER u2 IDENTIFIED BY 'password';
GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO u2;
REVOKE INSERT, UPDATE, DELETE ON mysql.* FROM u2;
```

 Another possibility is to revoke all `mysql` schema privileges but grant access to specific `mysql` tables or columns. This can be done even with a partial revoke on `mysql`. The following statements enable read-only access to `u1` within the `mysql` schema, but only for the `db` table and the `Host` and `User` columns of the `user` table:

```
CREATE USER u3 IDENTIFIED BY 'password';
GRANT ALL ON *.* TO u3;
REVOKE ALL ON mysql.* FROM u3;
GRANT SELECT ON mysql.db TO u3;
GRANT SELECT(Host,User) ON mysql.user TO u3;
```

