Understand OceanBase user management and access control in one article

This article mainly introduces the relevant content of user management and access control in the OceanBase (MySQL mode) security system by comparing MySQL and OceanBase, including user management, user operation authority control, network security access control, row-level authority control, role manage.

Author: Jin Changlong

Acson test engineer, responsible for the testing of DMP products.

Source of this article: original contribution

* Produced by the Aikesheng open source community, the original content is not allowed to be used without authorization, please contact the editor and indicate the source for reprinting.

This article mainly introduces the relevant content of user management and access control in the OceanBase (MySQL mode) security system by comparing MySQL and OceanBase, including user management, user operation authority control, network security access control, row-level authority control, role manage.

User Management

1.1 Basic concepts

tenant

OceanBase database tenant is a logical concept and a unit of resource allocation. Data among OceanBase database tenants is completely isolated, and each tenant is equivalent to a database instance of a traditional database.

OceanBase database tenants are divided into: system tenants and common tenants .

  • The OceanBase database pre-defines the system tenant ( systenant) for management, and its compatibility mode is MySQL
  • Ordinary tenants are divided into Oracle mode tenants and MySQL mode tenants

user

OceanBase database users are divided into: system tenant users and common tenant users .

  • The built-in system administrator of the system tenant is the user root
  • The built-in tenant administrator for the MySQL tenant is the user root
  • The built-in tenant administrator for the Oracle tenant is the user sys
  • When creating a user, if the tenant of the current session is a system tenant, the newly created user is a system tenant user, otherwise it is a common tenant user

1.2 Username Syntax

User names appearing in SQL statements (such as: CREATE USER, GRANT, SET PASSWORD) need to follow some rules, and test whether the performance of these rules is consistent in OceanBase and MySQL.

OceanBase

# 用户名称语法为 'user_name'@'host_name'
obclient [oceanbase]> create user 'test01'@'%' identified by '123456';
Query OK, 0 rows affected (0.017 sec)

# @'host_name' 部分是可选的
obclient [oceanbase]> create user test02;
Query OK, 0 rows affected (0.017 sec)

# 如果用户名和主机名作为不带引号的标识符是合法的,则无需将其引号括起来。如果 user_name 字符串包含特殊字符(如空格或 -),或者 host_name 字符串包含特殊字符或通配符(如 . 或 %),则必须使用引号
obclient [oceanbase]> create user test02@%;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near '%' at line 1
obclient [oceanbase]> create user test02@sun;
Query OK, 0 rows affected (0.027 sec)

# 主机值可以是主机名或 IP 地址(IPv4 或 IPv6)
obclient [oceanbase]> create user 'test02'@'127.0.0.1';
Query OK, 0 rows affected (0.021 sec)

# 主机名或 IP 地址值中允许使用 % 和 _ 通配符
obclient [oceanbase]> create user 'test02'@'%.mysql.com';
Query OK, 0 rows affected (0.016 sec)

# 对于指定为 IPv4 地址的主机值,可以提供一个网络掩码来指示要用于网络号的地址位数
obclient [oceanbase]> CREATE USER 'test02'@'198.51.100.0/255.255.255.0';
Query OK, 0 rows affected (0.017 sec)

# 指定为 IPv4 地址的主机值可以使用 CIDR 表示法写入
obclient [oceanbase]> CREATE USER 'test02'@'198.51.100.0/24';
Query OK, 0 rows affected (0.028 sec)

MySQL

# 用户名称语法为'user_name'@'host_name'
mysql [localhost:8031] {msandbox} ((none)) > create user 'test01'@'%' identified with mysql_native_password by '123456';
Query OK, 0 rows affected (0.03 sec)

# @'host_name' 部分是可选的
mysql [localhost:8031] {root} ((none)) > create user test02;
Query OK, 0 rows affected (0.03 sec)

# 如果用户名和主机名作为不带引号的标识符是合法的,则无需将其引号括起来。如果 user_name 字符串包含特殊字符(如空格或 -),或者 host_name 字符串包含特殊字符或通配符(如 . 或 %),则必须使用引号
mysql [localhost:8031] {root} ((none)) > create user test02@%;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%' at line 1
mysql [localhost:8031] {root} ((none)) > create user test02@sun;
Query OK, 0 rows affected (0.03 sec)

# 主机值可以是主机名或 IP 地址(IPv4 或 IPv6)
mysql [localhost:8031] {root} ((none)) > create user 'test02'@'127.0.0.1';
Query OK, 0 rows affected (0.01 sec)

# 主机名或 IP 地址值中允许使用 % 和 _ 通配符
mysql [localhost:8031] {root} ((none)) > create user 'test02'@'%.mysql.com';
Query OK, 0 rows affected (0.03 sec)

# 对于指定为 IPv4 地址的主机值,可以提供一个网络掩码来指示要用于网络号的地址位数
mysql [localhost:8031] {root} ((none)) > CREATE USER 'test02'@'198.51.100.0/255.255.255.0';
Query OK, 0 rows affected (0.02 sec)

# 从 MySQL 8.0.23 开始,指定为 IPv4 地址的主机值可以使用 CIDR 表示法写入
mysql [localhost:8031] {root} ((none)) > CREATE USER 'test02'@'198.51.100.0/24';
Query OK, 0 rows affected (0.04 sec)

Test results: Consistent performance .

1.3 User password setting

Common password allocation statements are: CREATE USER, ALTER USER, SET PASSWORD, to test the support of syntax in OceanBase and MySQL.

OceanBase

obclient [oceanbase]> CREATE USER 'jeffrey'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.018 sec)

obclient [oceanbase]> ALTER USER 'jeffrey'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.017 sec)

obclient [oceanbase]> SET PASSWORD FOR 'jeffrey'@'%' = 'password';
ERROR 1827 (42000): The password hash doesn't have the expected format. Check if the correct password algorithm is being used with the PASSWORD() function.

obclient [oceanbase]> SET PASSWORD FOR 'jeffrey'@'%' = PASSWORD('password');
Query OK, 0 rows affected (0.015 sec)

obclient [(none)]> ALTER USER USER() IDENTIFIED BY 'password';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near '() IDENTIFIED BY 'password'' at line 1

MySQL

mysql [localhost:8031] {msandbox} ((none)) > CREATE USER 'jeffrey'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.53 sec)

mysql [localhost:8031] {msandbox} ((none)) > ALTER USER 'jeffrey'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.00 sec)

mysql [localhost:8031] {msandbox} ((none)) > SET PASSWORD FOR 'jeffrey'@'%' = 'password';
Query OK, 0 rows affected (0.02 sec)

mysql [localhost:8031] {msandbox} ((none)) > SET PASSWORD FOR 'jeffrey'@'%' = PASSWORD('password');
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PASSWORD('password')' at line 1

mysql [localhost:8031] {jeffrey} ((none)) > ALTER USER USER() IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.03 sec)

Test Results:

  • The syntax of the two databases set passwordis slightly different.
  • The MySQL alter userstatement supports user()the function, but OceanBase does not support this writing method.

Change the password through the command line tool:

  • OceanBase: None for now.
  • MySQL: can be mysqladminmodified through the tool.

Password-specific issues:

  • OceanBase: None for now.
  • MySQL: If you are using MySQL replication, passwords currently used by replicas as CHANGE REPLICATION SOURCE TOstatements (from MySQL 8.0.23) or CHANGE MASTER TOto statements (prior to MySQL 8.0.23) are effectively limited to a length of 32 characters; if the password is longer, any Extra characters will be truncated. This is not due to any limitation normally imposed by the MySQL server, but a problem specific to MySQL replication.

1.4 User Lockout

Test whether the statement of OceanBase and MySQL supports user ALTER USERlocking .CREATE USER

OceanBase

obclient [oceanbase]> alter user 'jeffrey'@'%' account unlock;
Query OK, 0 rows affected (0.004 sec)

obclient [oceanbase]> alter user 'jeffrey'@'%' account lock;
Query OK, 0 rows affected (0.019 sec)

obclient [oceanbase]> create user 'jin'@'%' account lock;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near 'account lock' at line 1

OceanBase can confirm the user's lock status through the field __all_userin the table .is_locked

MySQL

mysql [localhost:8031] {msandbox} ((none)) > alter user 'jeffrey'@'%' account unlock;
Query OK, 0 rows affected (0.03 sec)

mysql [localhost:8031] {msandbox} ((none)) > alter user 'jeffrey'@'%' account lock;
Query OK, 0 rows affected (0.03 sec)

mysql [localhost:8031] {msandbox} ((none)) > create user 'jin'@'%' account lock;
Query OK, 0 rows affected (0.01 sec)

MySQL can confirm the user's lock status through the field mysql.userin the table .account_locked

Test Results:

  • OceanBase: ALTER USERsupports user locking, CREATE USERdoes not support user locking.
  • MySQL: ALTER USERand CREATE USERboth support user locking.

User operation authority control

2.1 Rights Management

OceanBase

The permissions of OceanBase (MySQL mode) are divided into 3 levels:

  1. Administrative permissions: Permissions that can affect the entire tenant, such as: modifying system settings, accessing all tables, etc.
  2. Database permission: It can affect the permission of all objects under a specific database, for example: creating and deleting tables, accessing tables and other permissions under the corresponding database.
  3. Object permissions: Permissions that can affect a specific object, for example: permission to access a specific table, view, or index.

For a list of all permissions of the current OceanBase (MySQL mode), you can query the OB official document Permission classification under MySQL mode .

MySQL

MySQL permissions are also divided into 3 levels:

  1. Administrative Privileges: Administrative privileges enable a user to manage the operation of the MySQL server. These privileges are global in that they are not specific to a particular database.

  2. Database Privileges: Database privileges apply to the database and all objects within it. These permissions can be granted for specific databases or globally so that they apply to all databases.

  3. Object privileges: Can be granted on a database object (e.g. table, index, view and stored routines).

MySQL also distinguishes between static permissions and dynamic permissions. For a specific list of permissions, please refer to the official MySQL document Privileges Provided by MySQL .

Rights management comparison

  1. User permission levels are divided into three levels, and the meanings expressed are consistent.
  2. The subdivision permissions are similar, and OceanBase still does not support some. According to the official document of OB, some fields are reserved in the authorization form but not yet supported.
  3. Several permissions unique to OceanBase: ALTER TENANT, ALTER SYSTEM, CREATE RESOURCE POOL, CREATE RESOURCE UNIT.
  4. OceanBase does not currently support dynamic permissions for MySQL.

2.2 Authorization statement

  1. Authorize GRANT
  2. revoke authorization REVOKE
  3. Authorization delegation WITH GRANT OPTION
  4. View user permissions SHOW GRANTS

Test results: OceanBase (MySQL mode) and MySQL are consistent in terms of authorization statements and syntax.

2.3 Authorization form

OceanBase

related library related table
mysql mysql.user
mysql.db
information_schema information_schema.COLUMN_PRIVILEGES
information_schema.SCHEMA_PRIVILEGES
information_schema.TABLE_PRIVILEGES
information_schema.USER_PRIVILEGES
oceanbase oceanbase.DBA_OB_DATABASE_PRIVILEGE
oceanbase.CDB_OB_DATABASE_PRIVILEGE

MySQL

related library related table
mysql user
global_grants
db
tables_priv
columns_priv
procs_priv
proxies_priv
default_roles
role_edges
password_history
information_schema information_schema.COLUMN_PRIVILEGES
information_schema.SCHEMA_PRIVILEGES
information_schema.TABLE_PRIVILEGES
information_schema.USER_PRIVILEGES

Test results: OceanBase (MySQL mode) and MySQL are quite different in the realization of the authorization table.

2.4 Partial withdrawal of permission restrictions

OceanBase

Partial revoking of global permissions is not supported.

MySQL

After the variable is turned on partial_revokes, the global permission can be partially revoked.

Test results: OceanBase does not support partial revoking of global permissions.

Network Security Access Control

OceanBase

The OceanBase database provides tenant whitelist policies to implement network security access control. The tenant whitelist refers to the list of clients that the tenant is allowed to log in to. The system supports the following tenant whitelist formats:

  • The format of the IP address, for example: 10.10.10.10, 10.10.10.11
  • In the form of subnet/mask, for example: 10.10.10.0/24
  • The form of fuzzy matching, for example: 10.10.10.% or 10.10.10._
  • Mixed formats, for example: 10.10.10.10, 10.10.10.11, 10.10.10.%, 10.10.10._, 10.10.10.0/24

ob_tcp_invited_nodesThe tenant's whitelist can be set by modifying the variable .

MySQL

MySQL itself does not find similar functionality.

Test results: OceanBase supports whitelist in network security access control, but MySQL itself does not support it.

Row level access control

OceanBase

The MySQL tenant mode does not support it, and it is implemented through Label Security in the Oracle tenant mode.

MySQL

There is no related functionality, it can be achieved indirectly through views/triggers .

Test results: Neither OceanBase (MySQL mode) nor MySQL supports row-level permission control.

role management

OceanBase

It is not supported in MySQL tenant mode, but it is supported in Oracle tenant mode.

MySQL

Support role management.

Test result: OceanBase does not support role management.

Here we think about a question: Because MySQL supports role management, what should we do if we migrate from MySQL to OceanBase?

From my personal understanding, a role is a collection of permissions, and its benefits are a convenient way to replace a single authorization and conceptualize all assigned permissions. So if you migrate from MySQL to OceanBase, theoretically, you can expand the permissions of the role.

summary

In terms of user management, OceanBase and MySQL follow the same rules for user names appearing in SQL statements, slightly different in SQL syntax for assigning passwords, and slightly different in SQL statement support for user locking.

In terms of permission management, the authorization statements and syntax of OceanBase and MySQL are consistent. Both databases have their own unique authorization tables. OceanBase does not support dynamic permissions and partial revoking of global permissions for the time being.

In terms of role management and row-level permission functions, OceanBase does not support MySQL tenant mode, but it can support Oracle tenant mode.

It is worth mentioning that OceanBase also provides a tenant whitelist function to control the clients that are allowed to log in.

About SQLE

The SQLE of the Akson open source community is a SQL auditing tool for database users and managers, which supports multi-scenario auditing, supports standardized online processes, natively supports MySQL auditing, and has scalable database types.

SQLE get

type address
Repository https://github.com/actiontech/sqle
document https://actiontech.github.io/sqle-docs/
release news https://github.com/actiontech/sqle/releases
Data audit plug-in development documentation https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_auditplugin/auditplugin_development.html

Guess you like

Origin blog.csdn.net/ActionTech/article/details/131420243