Account Categories 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  privilege directly, or because the session has activated a role that has the  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  privilege, the appropriate change between regular and system session takes place immediately, for that session only: These operations have no effect on existing sessions: Because role activation affects only sessions and not accounts, granting a role that has the  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. 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: 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: 1235 •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 •The  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  to it. This includes not granting  SYSTEM_USER  to any roles granted to the account. •By direct grant-table modification using statements such as  INSERT  and  UPDATE . This method is discouraged but possible for users with the appropriate privileges on the  mysql  system schema that contains the grant tables. •By using account-management statements such as  CREATE USER  and  GRANT . This is the preferred method. •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. •If the  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. Protecting System Accounts Against Manipulation by Regular Accounts •If a regular session activates a role with the  SYSTEM_USER  privilege, the session becomes a system session. •If a system session deactivates a role with the  SYSTEM_USER  privilege, the session becomes a regular session, unless some other role with the  SYSTEM_USER  privilege remains active.