Tenant
OceanBase Database's tenant is a logical concept that serves as a unit of resource allocation and the basis for managing database objects and resources. As a container for various database objects, tenants also serve as containers for resources such as CPU, memory, and I/O. Data is completely isolated between tenants, with each tenant being equivalent to an instance of a traditional database. Tenants are divided into system tenants and user tenants. The system tenant ("sys" tenant) is predefined for management purposes and compatible with MySQL. User tenants are further divided into Oracle mode tenants and MySQL mode tenants, commonly referred to as Oracle tenants and MySQL tenants respectively.
User
OceanBase Database users are classified into two categories: users in the sys tenant and users in a user tenant. The built-in system administrator of the sys tenant is the root user. The built-in tenant administrator of a MySQL tenant is the root user, and that of an Oracle tenant is the SYS user. When you create a user, if the current session is in the sys tenant, the created user belongs to the sys tenant. Otherwise, the user belongs to a user tenant. Users created by the administrator of the sys tenant or a user tenant can log in only to the current tenant. Users in a tenant must have unique usernames. However, users in different tenants can have the same usernames. Therefore, a user is globally identified by a username and a tenant name in the username@tenant name format.
Administrators in Oracle mode
OceanBase Database supports three administrator roles in Oracle mode to protect database security. The three administrator roles do not apply to the MySQL mode.
In real life, the abuse of privileges may occur if all privileges are granted to the same person. Likewise, to protect the security of a large database, it is necessary to grant the privileges of the database system to different user roles that take different responsibilities. In this way, the user roles can restrict and supervise each other, thereby ensuring the overall security of the system.
In the three-tier security management system, administrators are classified into database administrator (DBA), system security officer (SSO), and auditor.
DBA
Each database is managed by at least one DBA. The DBA can install and upgrade the database management system, set database parameters, create database objects, grant access privileges, import and export data, and back up and recover the database. In Oracle mode of OceanBase Database, the
SYSuser acts as the DBA.SSO
The SSO can configure audit settings for the database, define new database auditors, view audit records of the database, set security levels, scopes, and groups for the system, and define security flags for subjects and objects, thereby improving the overall security of the system. In Oracle mode of OceanBase Database, the
LBACSYSuser acts as the SSO.Auditor
The auditor implements force access control over the system, specifies objects and operations to be audited, defines new database auditors, views and analyzes audit records, and configures system strategies and flags. After auditing is set up, almost any operations performed by any users in the system can be tracked, to facilitate subsequent tracing. In Oracle mode of OceanBase Database, the
ORAAUDITORuser acts as the database auditor. The three administrator roles restrict each other and jointly manage the database.
Privilege
The logic of privilege check is the same as that in Oracle mode.
Privilege types
OceanBase Database supports the following two types of privileges in Oracle mode:
Object privileges: the privileges to operate on specific objects, such as the
ALTER,SELECT, andUPDATEprivileges on a table.System privileges: the privileges that allow users to perform specific database operations on one or all schemas.
System privileges provide much broader permissions than object privileges.
For more information about the privileges in Oracle mode, see Privilege types.
OceanBase Database supports the following three levels of privileges in MySQL mode:
Global privileges: the privileges to manage a tenant, such as modifying system settings and accessing all tables in the tenant.
Database privileges: the privileges to manage all objects in a database, such as creating or dropping tables in the database, and accessing those tables.
Object privileges: the privileges to manage a specific object, such as accessing a specific table, view, or index.
For more information about the privilege types in MySQL mode, see Privilege types.
Privilege delegation
Privilege delegation solves the problem due to the centralization of privileges to a limited number of authorizers. When you grant a privilege to a user by using a WITH ADMIN OPTION or WITH GRANT OPTION clause in the GRANT statement, you allow the user to grant the same privilege to other users. The revocation of object privileges extends to dependent users. For example, assuming that user A has granted privileges to user B and user B has granted privileges to user C, when you revoke an object privilege from user A, the object privilege is also revoked from user C. The revocation of system privileges does not extend to dependent users.
Role
In OceanBase Database, you can manage privileges by role. A role is a set of system and object privileges. A role can contain other roles. If you grant a role to a user, the user has all the privileges of the role.
In Oracle mode, when a new tenant is created, it has the following built-in roles by default:
DBArole: This role has most system privileges.RESOURCErole: Users with theRESOURCErole can only create database objects in their own schema.CONNECTrole: Users with theCONNECTrole only have the privilege to connect to databases.PUBLICrole: This role applies to all users in a tenant. By default, no privilege is granted to the role.STANDBY_REPLICATIONrole: This role applies to network-based Physical Standby Database scenarios.
For more information about role management in Oracle mode, see Manage roles.
By default, OceanBase Database does not provide built-in system roles in MySQL mode. For more information about role management in MySQL mode, see Manage roles.
Indirect privileges
User privileges are divided into direct and indirect privileges. Direct privileges are the system or object privileges that are granted to a user. Indirect privileges are those that are granted to the roles of a user. Most operations can be performed with direct or indirect privileges. Direct privileges are required to perform the following operations:
- When you create a view, you need privileges to access objects in a view.
- Privileges are required to execute statements in a named PL block with the definers' rights.
Privilege check
The system parses all the privileges required to execute an SQL statement and checks whether you have the corresponding privileges. When you attempt to perform a system operation but you do not have sufficient privileges, an error is returned indicating that you have insufficient privileges. When you attempt to access an object on which you do not have any privilege, an error is returned indicating that the object does not exist. If you have privileges other than the required ones on the object that you want to access, an error is returned indicating that you have insufficient privileges.