docs/en/08-operation/14-user.md
TDengine is configured by default with only one root user, who has the highest permissions. TDengine supports access control for system resources, databases, tables, views, and topics. The root user can set different access permissions for each user for different resources. This section introduces user and permission management in TDengine. User and permission management is a feature unique to TDengine Enterprise.
Starting from 3.4.0.0, TDengine Enterprise Edition implements a strict separation of three powers mechanism through role-based access control (RBAC). From versions 3.4.0.0 to 3.4.0.10, some syntax from version 3.3.x.y is not compatible. Starting from version 3.4.0.11, the syntax of version 3.3.x.y is also compatible. For more fine-grained permission management, it is recommended to use the new syntax introduced in version 3.4.0.0.
| Feature | 3.3.x.y- | 3.4.0.0+ |
|---|---|---|
| Basic User Management | ✓ | ✓ |
| RBAC Role Management | ✗ | ✓ |
| Separation of Three Powers (SYSDBA/SYSSEC/SYSAUDIT) | ✗ | ✓ |
| Fine-grained Permissions | ✗ | ✓ |
| Audit Database Permissions | ✗ | ✓ |
| Table Permissions | ✓ | ✓ |
| Row Permissions | ✗ | ✓ |
| Column Permissions | ✗ | ✓ |
Creating a user with the following syntax:
create user user_name pass'password' [sysinfo {1|0}] [createdb {1|0}]
The parameters are explained as follows.
! @ # $ % ^ & * ( ) - _ + = [ ] { } : ; > < ? | ~ , ., and this requirement is able to be closed by adding enableStrongPassword 0 in taos.cfg, or by the following SQL:alter all dnodes 'EnableStrongPassword' '0'
The following SQL can create a user named test with the password abc123!@# who can view system information.
create user test pass 'abc123!@#' sysinfo 1
To view user information in the system, use the following SQL.
show users;
You can also obtain user information in the system by querying the system table information_schema.ins_users, as shown below.
select * from information_schema.ins_users;
The SQL for modifying user information is as follows.
alter user user_name alter_user_clause
alter_user_clause: {
pass 'literal'
| enable value
| sysinfo value
| createdb value
}
The parameters are explained as follows.
The following SQL disables the user test.
alter user test enable 0
The SQL for deleting a user is as follows.
drop user user_name
Only the root user can manage system information such as users, nodes, vnode, qnode, snode, including querying, adding, deleting, and modifying.
In TDengine, permissions for databases and tables are divided into read (read) and write (write) types. These permissions can be granted individually or together to users.
The syntax for granting a user access to databases and tables is as follows.
grant privileges on resources [with tag_filter] to user_name
privileges: {
all,
| priv_type [, priv_type] ...
}
priv_type: {
read
| write
}
resources: {
dbname.tbname
| dbname.*
| *.*
}
The parameters are explained as follows.
The above SQL can authorize a database, all databases, a regular table or a supertable under a database, and it can also authorize all subtables under a supertable that meet filter conditions through a combination of dbname.tbname and the with clause. The following SQL grants read permission on the database power to the user test.
grant read on power to test
The following SQL grants all permissions on the supertable meters under the database power to the user test.
grant all on power.meters to test
The following SQL grants write permission to the user test for subtables of the supertable meters where the tag value groupId equals 1.
grant all on power.meters with groupId=1 to test
If a user is granted write permission to a database, then the user has both read and write permissions for all tables under this database. However, if a database has only read permission or even no read permission, table authorization allows the user to read or write some tables. See the reference manual for detailed authorization combinations.
In TDengine, view permissions are divided into read, write, and alter. These determine the user's access and operation permissions on the view. Here are the specific rules for view permissions:
To facilitate the sharing and use of views, TDengine introduces the concept of effective users of views (i.e., the creator of the view). Authorized users can use the read and write permissions of the effective user's databases, tables, and nested views. When a view is replaced, the effective user is also updated.
For detailed relationships between view operations and permission requirements, see the reference manual.
The syntax for view authorization is as follows.
grant privileges on [db_name.]view_name to user_name
privileges: {
all,
| priv_type [, priv_type] ...
}
priv_type: {
read
| write
alter
}
To grant read permission on the view view_name under the database power to the user test, the SQL is as follows.
grant read on power.view_name to test
To grant all permissions on the view view_name under the database power to the user test, the SQL is as follows.
grant all on power.view_name to test
Message subscription is a unique design of TDengine. To ensure the security of user subscription information, TDengine can authorize message subscriptions. Before using the message subscription authorization feature, users need to understand the following special usage rules:
The SQL syntax for message subscription authorization is as follows.
grant privileges on priv_level to user_name
privileges : {
all
| priv_type [, priv_type] ...
}
priv_type : {
subscribe
}
priv_level : {
topic_name
}
To grant subscription permission on the topic named topic_name to the user test, the SQL is as follows.
grant subscribe on topic_name to test
When a company has multiple database users, the following command can be used to query all the authorizations a specific user has, the SQL is as follows.
show user privileges
Due to the different characteristics of database access, data subscription, and views, the syntax for revoking specific authorizations also varies slightly. Below are the specific revocation authorization syntaxes for different authorization objects. The SQL for revoking database access authorization is as follows.
revoke privileges on priv_level [with tag_condition] from user_name
privileges : {
all
| priv_type [, priv_type] ...
}
priv_type : {
read
| write
}
priv_level : {
dbname.tbname
| dbname.*
| *.*
}
The SQL for revoking view permissions is as follows.
revoke privileges on [db_name.]view_name from user_name
privileges: {
all,
| priv_type [, priv_type] ...
}
priv_type: {
read
| write
| alter
}
The SQL for revoking data subscription permissions is as follows.
revoke privileges on priv_level from user_name
privileges : {
all
| priv_type [, priv_type] ...
}
priv_type : {
subscribe
}
priv_level : {
topic_name
}
The SQL for revoking all permissions of user test on the database power is as follows.
revoke all on power from test
The SQL for revoking the read permission of user test on the view view_name of the database power is as follows.
revoke read on power.view_name from test
The SQL for revoking the subscribe permission of user test on the message subscription topic_name is as follows.
revoke subscribe on topic_name from test
Starting from 3.4.0.0, TDengine Enterprise Edition implements a separation of three powers mechanism through role-based access control (RBAC). The management permissions of the root user are split into SYSDBA, SYSSEC, and SYSAUDIT three system management permissions, thus achieving effective isolation and checks and balances of permissions.
For detailed information, please refer to the Permission Management section.