From aa9e1b2e8869e0f31efa2f14e223a6d399e026a3 Mon Sep 17 00:00:00 2001 From: ireneontheway Date: Mon, 27 Jul 2020 17:41:34 +0800 Subject: [PATCH 1/4] Update user-account-management.md --- user-account-management.md | 115 +++++++++++++++++++++++++++++++++---- 1 file changed, 104 insertions(+), 11 deletions(-) diff --git a/user-account-management.md b/user-account-management.md index cb3300d53800f..720bc86a34903 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -37,22 +37,107 @@ You can create TiDB accounts in two ways: It is recommended to use the account-management statements, because manipulating the privilege tables directly can lead to incomplete updates. You can also create accounts by using third party GUI tools. -The following example uses the `CREATE USER` and `GRANT` statements to set up four accounts: +{{< copyable "sql" >}} ```sql -mysql> CREATE USER 'finley'@'localhost' IDENTIFIED BY 'some_pass'; -mysql> GRANT ALL PRIVILEGES ON *.* TO 'finley'@'localhost' WITH GRANT OPTION; -mysql> CREATE USER 'finley'@'%' IDENTIFIED BY 'some_pass'; -mysql> GRANT ALL PRIVILEGES ON *.* TO 'finley'@'%' WITH GRANT OPTION; -mysql> CREATE USER 'admin'@'localhost' IDENTIFIED BY 'admin_pass'; -mysql> GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost'; -mysql> CREATE USER 'dummy'@'localhost'; +CREATE USER [IF NOT EXISTS] user [IDENTIFIED BY 'auth_string']; ``` -To see the privileges for an account, use `SHOW GRANTS`: +After you assign the password, TiDB encrypts and stores the `auth_string` in the `mysql.user` table. + +{{< copyable "sql" >}} + +```sql +CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; +``` + +The name of TiDB user account consists of a user name and a host name. The syntax of the account name is 'user_name'@'host_name'. + +- `user_name` is case sensitive. + +- `host_name` is a host name or IP address, which allows to use the wild card % or _. For example, the hostname '%' matches all hosts, and the hostname '192.168.1.%' matches all hosts in the subnet. + +The host supports fuzzy matching: + +{{< copyable "sql" >}} + +```sql +CREATE USER 'test'@'192.168.10.%'; +``` + +The `test` user is allowed to log in from any hosts on the `192.168.10` subnet. + +If the host is not specified, all IPs can log in by default. If no password is specified, the default is null: + +{{< copyable "sql" >}} + +```sql +CREATE USER 'test'; +``` + +Equivalent to: + +{{< copyable "sql" >}} + +```sql +CREATE USER 'test'@'%' IDENTIFIED BY ''; +``` + +If the user specified does not exist, the behavior of automatically creating users depends on `sql_mode`. If the `sql_mode` includes `NO_AUTO_CREATE_USER`, `GRANT` statements will not return an error and create users. + +If the `sql_mode` does not include `NO_AUTO_CREATE_USER`, the following example uses the `CREATE USER` and `GRANT` statements to set up four accounts: + +{{< copyable "sql" >}} + +```sql +CREATE USER 'finley'@'localhost' IDENTIFIED BY 'some_pass'; +``` + +{{< copyable "sql" >}} + +```sql +GRANT ALL PRIVILEGES ON *.* TO 'finley'@'localhost' WITH GRANT OPTION; +``` + +{{< copyable "sql" >}} + +```sql +CREATE USER 'finley'@'%' IDENTIFIED BY 'some_pass'; +``` + +{{< copyable "sql" >}} + +```sql +GRANT ALL PRIVILEGES ON *.* TO 'finley'@'%' WITH GRANT OPTION; +``` + +{{< copyable "sql" >}} + +```sql +CREATE USER 'admin'@'localhost' IDENTIFIED BY 'admin_pass'; +``` + +{{< copyable "sql" >}} ```sql -mysql> SHOW GRANTS FOR 'admin'@'localhost'; +GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost'; +``` + +{{< copyable "sql" >}} + +```sql +CREATE USER 'dummy'@'localhost'; +``` + +To see the privileges for an account, use the `SHOW GRANTS` statement: + +{{< copyable "sql" >}} + +```sql +SHOW GRANTS FOR 'admin'@'localhost'; +``` + +``` +-----------------------------------------------------+ | Grants for admin@localhost | +-----------------------------------------------------+ @@ -64,10 +149,14 @@ mysql> SHOW GRANTS FOR 'admin'@'localhost'; To remove a user account, use the `DROP USER` statement: +{{< copyable "sql" >}} + ```sql mysql> DROP USER 'test'@'localhost'; ``` +This operation will clear user's records in the `mysql.user` table and the related records in the privilege table. + ## Reserved user accounts TiDB creates the `'root'@'%'` default account during the database initialization. @@ -107,14 +196,18 @@ TiDB stores passwords in the `mysql.user` system database. Operations that assig skip-grant-table = true ``` -2. Use `root` to log in and then modify the password: +2. Start TiDB with the modified configuration. Use `root` to log in and then modify the password: ```bash mysql -h 127.0.0.1 -P 4000 -u root ``` +When the `skip-grant-table` is set, starting the TiDB process will increase the user check of the operating system, and only the `root` user of the operating system can start the TiDB process. + ## `FLUSH PRIVILEGES` +Information related to users and privileges is stored in the TiKV server, and TiDB caches this information inside the process. Generally, modification of the related information through CREATE USER, GRANT and other statements takes effect quickly in the entire cluster. If affected by the network or other factors, normally the information will take effect in about 15 minutes at most as TiDB will periodically update the cache information. + If you modified the privilege tables directly, run the following command to apply changes immediately: ```sql From 38536d16786ad0d6f49201628bf54303838705e6 Mon Sep 17 00:00:00 2001 From: ireneontheway <48651140+ireneontheway@users.noreply.github.com> Date: Tue, 28 Jul 2020 11:48:13 +0800 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: tiancaiamao --- user-account-management.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/user-account-management.md b/user-account-management.md index 720bc86a34903..f47dcbc3cc7ff 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -67,7 +67,7 @@ CREATE USER 'test'@'192.168.10.%'; The `test` user is allowed to log in from any hosts on the `192.168.10` subnet. -If the host is not specified, all IPs can log in by default. If no password is specified, the default is null: +If the host is not specified, the user is allowed to log in from any IP. If no password is specified, the default is null: {{< copyable "sql" >}} @@ -83,7 +83,7 @@ Equivalent to: CREATE USER 'test'@'%' IDENTIFIED BY ''; ``` -If the user specified does not exist, the behavior of automatically creating users depends on `sql_mode`. If the `sql_mode` includes `NO_AUTO_CREATE_USER`, `GRANT` statements will not return an error and create users. +If the user specified does not exist, the behavior of automatically creating users depends on `sql_mode`. If the `sql_mode` includes `NO_AUTO_CREATE_USER`, `GRANT` statement will not return an error and create users. If the `sql_mode` does not include `NO_AUTO_CREATE_USER`, the following example uses the `CREATE USER` and `GRANT` statements to set up four accounts: @@ -202,11 +202,11 @@ TiDB stores passwords in the `mysql.user` system database. Operations that assig mysql -h 127.0.0.1 -P 4000 -u root ``` -When the `skip-grant-table` is set, starting the TiDB process will increase the user check of the operating system, and only the `root` user of the operating system can start the TiDB process. +When the `skip-grant-table` is set, starting the TiDB process will check the user to be an administrator of the operating system, and only the `root` user of the operating system can start the TiDB process. ## `FLUSH PRIVILEGES` -Information related to users and privileges is stored in the TiKV server, and TiDB caches this information inside the process. Generally, modification of the related information through CREATE USER, GRANT and other statements takes effect quickly in the entire cluster. If affected by the network or other factors, normally the information will take effect in about 15 minutes at most as TiDB will periodically update the cache information. +Information related to users and privileges is stored in the TiKV server, and TiDB caches this information inside the process. Generally, modification of the related information through CREATE USER, GRANT and other statements takes effect quickly within the entire cluster. If the operation is affected by some factors such as network temporary unavailable, it will take effect in about 15 minutes as TiDB will periodically reload the cache information. If you modified the privilege tables directly, run the following command to apply changes immediately: From f7060d4ecf7cc1659b0223d6ab7b1cc01cebf566 Mon Sep 17 00:00:00 2001 From: ireneontheway <48651140+ireneontheway@users.noreply.github.com> Date: Tue, 28 Jul 2020 12:53:25 +0800 Subject: [PATCH 3/4] Apply suggestions from code review Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- user-account-management.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/user-account-management.md b/user-account-management.md index f47dcbc3cc7ff..eb3cec2628300 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -51,11 +51,11 @@ After you assign the password, TiDB encrypts and stores the `auth_string` in the CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; ``` -The name of TiDB user account consists of a user name and a host name. The syntax of the account name is 'user_name'@'host_name'. +The name of a TiDB account consists of a user name and a hostname. The syntax of the account name is 'user_name'@'host_name'. - `user_name` is case sensitive. -- `host_name` is a host name or IP address, which allows to use the wild card % or _. For example, the hostname '%' matches all hosts, and the hostname '192.168.1.%' matches all hosts in the subnet. +- `host_name` is a hostname or IP address, which supports the wild card `%` or ` _`. For example, the hostname `'%'` matches all hosts, and the hostname `'192.168.1.%'` matches all hosts in the subnet. The host supports fuzzy matching: @@ -67,7 +67,7 @@ CREATE USER 'test'@'192.168.10.%'; The `test` user is allowed to log in from any hosts on the `192.168.10` subnet. -If the host is not specified, the user is allowed to log in from any IP. If no password is specified, the default is null: +If the host is not specified, the user is allowed to log in from any IP. If no password is specified, the default is empty password: {{< copyable "sql" >}} @@ -83,9 +83,9 @@ Equivalent to: CREATE USER 'test'@'%' IDENTIFIED BY ''; ``` -If the user specified does not exist, the behavior of automatically creating users depends on `sql_mode`. If the `sql_mode` includes `NO_AUTO_CREATE_USER`, `GRANT` statement will not return an error and create users. +If the specified user does not exist, the behavior of automatically creating users depends on `sql_mode`. If the `sql_mode` includes `NO_AUTO_CREATE_USER`, the `GRANT` statement will not create users with an error returned. -If the `sql_mode` does not include `NO_AUTO_CREATE_USER`, the following example uses the `CREATE USER` and `GRANT` statements to set up four accounts: +For example, assume that the `sql_mode` does not include `NO_AUTO_CREATE_USER`, and you use the following `CREATE USER` and `GRANT` statements to create four accounts: {{< copyable "sql" >}} @@ -129,7 +129,7 @@ GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost'; CREATE USER 'dummy'@'localhost'; ``` -To see the privileges for an account, use the `SHOW GRANTS` statement: +To see the privileges granted for an account, use the `SHOW GRANTS` statement: {{< copyable "sql" >}} @@ -152,10 +152,10 @@ To remove a user account, use the `DROP USER` statement: {{< copyable "sql" >}} ```sql -mysql> DROP USER 'test'@'localhost'; +DROP USER 'test'@'localhost'; ``` -This operation will clear user's records in the `mysql.user` table and the related records in the privilege table. +This operation clears the user's records in the `mysql.user` table and the related records in the privilege table. ## Reserved user accounts @@ -202,11 +202,11 @@ TiDB stores passwords in the `mysql.user` system database. Operations that assig mysql -h 127.0.0.1 -P 4000 -u root ``` -When the `skip-grant-table` is set, starting the TiDB process will check the user to be an administrator of the operating system, and only the `root` user of the operating system can start the TiDB process. +When the `skip-grant-table` is set, starting the TiDB process will check whether the user is an administrator of the operating system, and only the `root` user of the operating system can start the TiDB process. ## `FLUSH PRIVILEGES` -Information related to users and privileges is stored in the TiKV server, and TiDB caches this information inside the process. Generally, modification of the related information through CREATE USER, GRANT and other statements takes effect quickly within the entire cluster. If the operation is affected by some factors such as network temporary unavailable, it will take effect in about 15 minutes as TiDB will periodically reload the cache information. +Information related to users and privileges is stored in the TiKV server, and TiDB caches this information inside the process. Generally, modification of the related information through `CREATE USER`, `GRANT`, and other statements takes effect quickly within the entire cluster. If the operation is affected by some factors such as temporarily unavailable network, the modification will take effect in about 15 minutes because TiDB will periodically reload the cache information. If you modified the privilege tables directly, run the following command to apply changes immediately: From a11bb26b813cb74bff9f80eb1ac49b059fb6899c Mon Sep 17 00:00:00 2001 From: ireneontheway <48651140+ireneontheway@users.noreply.github.com> Date: Tue, 28 Jul 2020 12:54:34 +0800 Subject: [PATCH 4/4] Update user-account-management.md --- user-account-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user-account-management.md b/user-account-management.md index eb3cec2628300..da9281b7dbb68 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -55,7 +55,7 @@ The name of a TiDB account consists of a user name and a hostname. The syntax of - `user_name` is case sensitive. -- `host_name` is a hostname or IP address, which supports the wild card `%` or ` _`. For example, the hostname `'%'` matches all hosts, and the hostname `'192.168.1.%'` matches all hosts in the subnet. +- `host_name` is a hostname or IP address, which supports the wild card `%` or `_`. For example, the hostname `'%'` matches all hosts, and the hostname `'192.168.1.%'` matches all hosts in the subnet. The host supports fuzzy matching: