Administration Management

IoTDB provides users with account privilege management operations, so as to ensure data security.

We will show you basic user privilege management operations through the following specific examples. Detailed SQL syntax and usage details can be found in SQL Documentation. At the same time, in the JAVA programming environment, you can use the Java JDBC to execute privilege management statements in a single or batch mode.

Basic Concepts

User

The user is the legal user of the database. A user corresponds to a unique username and has a password as a means of authentication. Before using a database, a person must first provide a legitimate username and password to make himself/herself a user.

Privilege

The database provides a variety of operations, and not all users can perform all operations. If a user can perform an operation, the user is said to have the privilege to perform the operation. privileges are divided into data management privilege (such as adding, deleting and modifying data) and authority management privilege (such as creation and deletion of users and roles, granting and revoking of privileges, etc.). Data management privilege often needs a path to limit its effective range, which is a subtree rooted at the path’s corresponding node.

Role

A role is a set of privileges and has a unique role name as an identifier. A user usually corresponds to a real identity (such as a traffic dispatcher), while a real identity may correspond to multiple users. These users with the same real identity tend to have the same privileges. Roles are abstractions that can unify the management of such privileges.

Default User

There is a default user in IoTDB after the initial installation: root, and the default password is root. This user is an administrator user, who cannot be deleted and has all the privileges. Neither can new privileges be granted to the root user nor can privileges owned by the root user be deleted.

Privilege Management Operation Examples

According to the sample dataAdministration - 图1 (opens new window), the sample data of IoTDB might belong to different power generation groups such as ln, sgcc, etc. Different power generation groups do not want others to obtain their own database data, so we need to have data privilege isolated at the group layer.

Create User

We use CREATE USER <userName> <password> to create users. For example, we can create two users for ln and sgcc groups, named ln_write_user and sgcc_write_user, with both passwords being write_pwd. The SQL statement is:

  1. CREATE USER ln_write_user 'write_pwd'
  2. CREATE USER sgcc_write_user 'write_pwd'

Then use the following SQL statement to show the user:

  1. LIST USER

As can be seen from the result shown below, the two users have been created:

  1. +---------------+
  2. | user|
  3. +---------------+
  4. | ln_write_user|
  5. | root|
  6. |sgcc_write_user|
  7. +---------------+
  8. Total line number = 3
  9. It costs 0.004s

Grant User Privilege

At this point, although two users have been created, they do not have any privileges, so they can not operate on the database. For example, we use ln_write_user to write data in the database, the SQL statement is:

  1. INSERT INTO root.ln.wf01.wt01(timestamp,status) values(1509465600000,true)

The SQL statement will not be executed and the corresponding error prompt is given as follows:

  1. Msg: 602: No permissions for this operation INSERT

Now, we grant the two users write privileges to the corresponding storage groups, and try to write data again.

We use GRANT USER <userName> PRIVILEGES <privileges> ON <nodeName> to grant user privileges. For example:

  1. GRANT USER ln_write_user PRIVILEGES INSERT_TIMESERIES on root.ln
  2. GRANT USER sgcc_write_user PRIVILEGES INSERT_TIMESERIES on root.sgcc
  3. INSERT INTO root.ln.wf01.wt01(timestamp, status) values(1509465600000, true)

The execution result is as follows:

  1. IoTDB> GRANT USER ln_write_user PRIVILEGES INSERT_TIMESERIES on root.ln
  2. Msg: The statement is executed successfully.
  3. IoTDB> GRANT USER sgcc_write_user PRIVILEGES INSERT_TIMESERIES on root.sgcc
  4. Msg: The statement is executed successfully.
  5. IoTDB> INSERT INTO root.ln.wf01.wt01(timestamp, status) values(1509465600000, true)
  6. Msg: The statement is executed successfully.

Revoker User Privilege

After granting user privileges, we could use REVOKE USER <userName> PRIVILEGES <privileges> ON <nodeName> to revoke the granted user privileges. For example:

  1. REVOKE USER ln_write_user PRIVILEGES INSERT_TIMESERIES on root.ln
  2. REVOKE USER sgcc_write_user PRIVILEGES INSERT_TIMESERIES on root.sgcc
  3. INSERT INTO root.ln.wf01.wt01(timestamp, status) values(1509465600000, true)

The execution result is as follows:

  1. REVOKE USER ln_write_user PRIVILEGES INSERT_TIMESERIES on root.ln
  2. Msg: The statement is executed successfully.
  3. REVOKE USER sgcc_write_user PRIVILEGES INSERT_TIMESERIES on root.sgcc
  4. Msg: The statement is executed successfully.
  5. INSERT INTO root.ln.wf01.wt01(timestamp, status) values(1509465600000, true)
  6. Msg: 602: No permissions for this operation INSERT

SQL Statements

Here are all related SQL statements:

  • Create User
  1. CREATE USER <userName> <password>;
  2. Eg: IoTDB > CREATE USER thulab 'pwd';
  • Delete User
  1. DROP USER <userName>;
  2. Eg: IoTDB > DROP USER xiaoming;
  • Create Role
  1. CREATE ROLE <roleName>;
  2. Eg: IoTDB > CREATE ROLE admin;
  • Delete Role
  1. DROP ROLE <roleName>;
  2. Eg: IoTDB > DROP ROLE admin;
  • Grant User Privileges
  1. GRANT USER <userName> PRIVILEGES <privileges> ON <nodeName>;
  2. Eg: IoTDB > GRANT USER tempuser PRIVILEGES DELETE_TIMESERIES on root.ln;
  • Grant Role Privileges
  1. GRANT ROLE <roleName> PRIVILEGES <privileges> ON <nodeName>;
  2. Eg: IoTDB > GRANT ROLE temprole PRIVILEGES DELETE_TIMESERIES ON root.ln;
  • Grant User Role
  1. GRANT <roleName> TO <userName>;
  2. Eg: IoTDB > GRANT temprole TO tempuser;
  • Revoke User Privileges
  1. REVOKE USER <userName> PRIVILEGES <privileges> ON <nodeName>;
  2. Eg: IoTDB > REVOKE USER tempuser PRIVILEGES DELETE_TIMESERIES on root.ln;
  • Revoke Role Privileges
  1. REVOKE ROLE <roleName> PRIVILEGES <privileges> ON <nodeName>;
  2. Eg: IoTDB > REVOKE ROLE temprole PRIVILEGES DELETE_TIMESERIES ON root.ln;
  • Revoke Role From User
  1. REVOKE <roleName> FROM <userName>;
  2. Eg: IoTDB > REVOKE temprole FROM tempuser;
  • List Users
  1. LIST USER
  2. Eg: IoTDB > LIST USER
  • List Roles
  1. LIST ROLE
  2. Eg: IoTDB > LIST ROLE
  • List Privileges
  1. LIST PRIVILEGES USER <username> ON <path>;
  2. Eg: IoTDB > LIST PRIVILEGES USER sgcc_wirte_user ON root.sgcc;
  • List Privileges of Roles
  1. LIST ROLE PRIVILEGES <roleName>
  2. Eg: IoTDB > LIST ROLE PRIVILEGES actor;
  • List Privileges of Roles(On Specific Path)
  1. LIST PRIVILEGES ROLE <roleName> ON <path>;
  2. Eg: IoTDB > LIST PRIVILEGES ROLE wirte_role ON root.sgcc;
  • List Privileges of Users
  1. LIST USER PRIVILEGES <username> ;
  2. Eg: IoTDB > LIST USER PRIVILEGES tempuser;
  • List Roles of User
  1. LIST ALL ROLE OF USER <username> ;
  2. Eg: IoTDB > LIST ALL ROLE OF USER tempuser;
  • List Users of Role
  1. LIST ALL USER OF ROLE <roleName>;
  2. Eg: IoTDB > LIST ALL USER OF ROLE roleuser;
  • Alter Password
  1. ALTER USER <username> SET PASSWORD <password>;
  2. Eg: IoTDB > ALTER USER tempuser SET PASSWORD 'newpwd';

Other Instructions

The Relationship among Users, Privileges and Roles

A Role is a set of privileges, and privileges and roles are both attributes of users. That is, a role can have several privileges and a user can have several roles and privileges (called the user’s own privileges).

At present, there is no conflicting privilege in IoTDB, so the real privileges of a user is the union of the user’s own privileges and the privileges of the user’s roles. That is to say, to determine whether a user can perform an operation, it depends on whether one of the user’s own privileges or the privileges of the user’s roles permits the operation. The user’s own privileges and privileges of the user’s roles may overlap, but it does not matter.

It should be noted that if users have a privilege (corresponding to operation A) themselves and their roles contain the same privilege, then revoking the privilege from the users themselves alone can not prohibit the users from performing operation A, since it is necessary to revoke the privilege from the role, or revoke the role from the user. Similarly, revoking the privilege from the users’s roles alone can not prohibit the users from performing operation A.

At the same time, changes to roles are immediately reflected on all users who own the roles. For example, adding certain privileges to roles will immediately give all users who own the roles corresponding privileges, and deleting certain privileges will also deprive the corresponding users of the privileges (unless the users themselves have the privileges).

List of Privileges Included in the System

List of privileges Included in the System

privilege NameInterpretation
SET_STORAGE_GROUPset storage groups; path dependent
CREATE_TIMESERIEScreate timeseries; path dependent
INSERT_TIMESERIESinsert data; path dependent
READ_TIMESERIESquery data; path dependent
DELETE_TIMESERIESdelete data or timeseries, deactivate template; path dependent
DELETE_STORAGE_GROUPdelete storage groups; path dependent
CREATE_USERcreate users; path independent
DELETE_USERdelete users; path independent
MODIFY_PASSWORDmodify passwords for all users; path independent; (Those who do not have this privilege can still change their own asswords. )
LIST_USERlist all users; list a user’s privileges; list a user’s roles; list users of role with four kinds of operation privileges; path independent
GRANT_USER_PRIVILEGEgrant user privileges; path independent
REVOKE_USER_PRIVILEGErevoke user privileges; path independent
GRANT_USER_ROLEgrant user roles; path independent
REVOKE_USER_ROLErevoke user roles; path independent
CREATE_ROLEcreate roles; path independent
DELETE_ROLEdelete roles; path independent
LIST_ROLElist all roles; list the privileges of a role; list the three kinds of operation privileges of all users owning a role; path independent
GRANT_ROLE_PRIVILEGEgrant role privileges; path independent
REVOKE_ROLE_PRIVILEGErevoke role privileges; path independent
CREATE_FUNCTIONregister UDFs; path independent
DROP_FUNCTIONderegister UDFs; path independent
CREATE_TRIGGERcreate triggers; path dependent
DROP_TRIGGERdrop triggers; path dependent
START_TRIGGERstart triggers; path dependent
STOP_TRIGGERstop triggers; path dependent
CREATE_CONTINUOUS_QUERYcreate continuous queries; path independent
DROP_CONTINUOUS_QUERYdrop continuous queries; path independent
UPDATE_TEMPLATEcreate, drop, append and prune schema template; path independent
APPLY_TEMPLATEset, unset and activate schema template; path dependent

Username Restrictions

IoTDB specifies that the character length of a username should not be less than 4, and the username cannot contain spaces.

Password Restrictions

IoTDB specifies that the character length of a password should have no less than 4 character length, and no spaces. The password is encrypted with MD5.

Role Name Restrictions

IoTDB specifies that the character length of a role name should have no less than 4 character length, and no spaces.