|
| 1 | +--- |
| 2 | +title: Column-Level Privilege Management |
| 3 | +summary: TiDB supports a MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table using `GRANT` or `REVOKE`, achieving finer-grained access control. |
| 4 | +--- |
| 5 | + |
| 6 | +# Column-Level Privilege Management |
| 7 | + |
| 8 | +Starting from v8.5.6, TiDB supports a MySQL-compatible column-level privilege management mechanism. With column-level privileges, you can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns in a specified table, achieving finer-grained data access control. |
| 9 | + |
| 10 | +> **Note:** |
| 11 | +> |
| 12 | +> Although MySQL syntax allows column-level syntax such as `REFERENCES(col_name)`, `REFERENCES` itself is a database-level or table-level privilege used for foreign key-related privilege checks. Therefore, column-level `REFERENCES` does not produce any actual column-level privilege effect in MySQL. TiDB's behavior is consistent with MySQL. |
| 13 | +
|
| 14 | +## Syntax |
| 15 | + |
| 16 | +The syntax for granting and revoking column-level privileges is similar to that for table-level privileges, with the following differences: |
| 17 | + |
| 18 | +- Write the column name list after the **privilege type**, not after the **table name**. |
| 19 | +- Multiple column names are separated by commas (`,`). |
| 20 | + |
| 21 | +```sql |
| 22 | +GRANT priv_type(col_name [, col_name] ...) [, priv_type(col_name [, col_name] ...)] ... |
| 23 | + ON db_name.tbl_name |
| 24 | + TO 'user'@'host'; |
| 25 | + |
| 26 | +REVOKE priv_type(col_name [, col_name] ...) [, priv_type(col_name [, col_name] ...)] ... |
| 27 | + ON db_name.tbl_name |
| 28 | + FROM 'user'@'host'; |
| 29 | +``` |
| 30 | + |
| 31 | +Where: |
| 32 | + |
| 33 | +* `priv_type` supports `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES`. |
| 34 | +* The `ON` clause must specify a table, for example, `test.tbl`. |
| 35 | +* A single `GRANT` or `REVOKE` statement can include multiple privilege items, and each privilege item can specify its own list of column names. |
| 36 | + |
| 37 | +For example, the following statement grants `SELECT` privileges on `col1` and `col2` and `UPDATE` privilege on `col3` to the user: |
| 38 | + |
| 39 | +```sql |
| 40 | +GRANT SELECT(col1, col2), UPDATE(col3) ON test.tbl TO 'user'@'host'; |
| 41 | +``` |
| 42 | + |
| 43 | +## Example: Grant column-level privileges |
| 44 | + |
| 45 | +The following example grants user `newuser` the `SELECT` privilege on `col1` and `col2` in table `test.tbl`, and grants the same user the `UPDATE` privilege on `col3`: |
| 46 | + |
| 47 | +```sql |
| 48 | +CREATE DATABASE IF NOT EXISTS test; |
| 49 | +USE test; |
| 50 | + |
| 51 | +DROP TABLE IF EXISTS tbl; |
| 52 | +CREATE TABLE tbl (col1 INT, col2 INT, col3 INT); |
| 53 | + |
| 54 | +DROP USER IF EXISTS 'newuser'@'%'; |
| 55 | +CREATE USER 'newuser'@'%'; |
| 56 | + |
| 57 | +GRANT SELECT(col1, col2), UPDATE(col3) ON test.tbl TO 'newuser'@'%'; |
| 58 | +SHOW GRANTS FOR 'newuser'@'%'; |
| 59 | +``` |
| 60 | + |
| 61 | +``` |
| 62 | ++---------------------------------------------------------------------+ |
| 63 | +| Grants for newuser@% | |
| 64 | ++---------------------------------------------------------------------+ |
| 65 | +| GRANT USAGE ON *.* TO 'newuser'@'%' | |
| 66 | +| GRANT SELECT(col1, col2), UPDATE(col3) ON test.tbl TO 'newuser'@'%' | |
| 67 | ++---------------------------------------------------------------------+ |
| 68 | +``` |
| 69 | + |
| 70 | +In addition to using `SHOW GRANTS`, you can also view column-level privilege information by querying `INFORMATION_SCHEMA.COLUMN_PRIVILEGES`. |
| 71 | + |
| 72 | +## Example: Revoke column-level privileges |
| 73 | + |
| 74 | +The following example revokes the `SELECT` privilege on column `col2` from user `newuser`: |
| 75 | + |
| 76 | +```sql |
| 77 | +REVOKE SELECT(col2) ON test.tbl FROM 'newuser'@'%'; |
| 78 | +SHOW GRANTS FOR 'newuser'@'%'; |
| 79 | +``` |
| 80 | + |
| 81 | +``` |
| 82 | ++---------------------------------------------------------------+ |
| 83 | +| Grants for newuser@% | |
| 84 | ++---------------------------------------------------------------+ |
| 85 | +| GRANT USAGE ON *.* TO 'newuser'@'%' | |
| 86 | +| GRANT SELECT(col1), UPDATE(col3) ON test.tbl TO 'newuser'@'%' | |
| 87 | ++---------------------------------------------------------------+ |
| 88 | +``` |
| 89 | + |
| 90 | +## Example: Column-level privilege access control |
| 91 | + |
| 92 | +After granting or revoking column-level privileges, TiDB performs privilege checks on columns referenced in SQL statements. For example: |
| 93 | + |
| 94 | +* `SELECT` statements: `SELECT` column privileges affect columns referenced in the `SELECT` list as well as `WHERE`, `ORDER BY`, and other clauses. |
| 95 | +* `UPDATE` statements: columns being updated in the `SET` clause require `UPDATE` column privileges. Columns read in expressions or conditions usually also require `SELECT` column privileges. |
| 96 | +* `INSERT` statements: columns being written to require `INSERT` column privileges. `INSERT INTO t VALUES (...)` is equivalent to writing values to all columns in table definition order. |
| 97 | + |
| 98 | +In the following example, user `newuser` can only query `col1` and update `col3`: |
| 99 | + |
| 100 | +```sql |
| 101 | +-- Execute as newuser |
| 102 | +SELECT col1 FROM tbl; |
| 103 | +SELECT * FROM tbl; -- Error (missing SELECT column privilege for col2, col3) |
| 104 | + |
| 105 | +UPDATE tbl SET col3 = 1; |
| 106 | +UPDATE tbl SET col1 = 2; -- Error (missing UPDATE column privilege for col1) |
| 107 | + |
| 108 | +UPDATE tbl SET col3 = col1; |
| 109 | +UPDATE tbl SET col3 = col3 + 1; -- Error (missing SELECT column privilege for col3) |
| 110 | +UPDATE tbl SET col3 = col1 WHERE col1 > 0; |
| 111 | +``` |
| 112 | + |
| 113 | +## Compatibility differences with MySQL |
| 114 | + |
| 115 | +TiDB's column-level privileges are generally compatible with MySQL. However, there are differences in the following scenarios: |
| 116 | + |
| 117 | +| Scenario | TiDB | MySQL | |
| 118 | +| :--------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 119 | +| Revoking column-level privileges not granted to a user | `REVOKE` executes successfully. | When `IF EXISTS` is not used, `REVOKE` returns an error. | |
| 120 | +| Execution order of column pruning and `SELECT` privilege check | `SELECT` column privileges are checked before column pruning. For example, executing `SELECT a FROM (SELECT a, b FROM t) s` requires `SELECT` column privileges on both `t.a` and `t.b`. | Column pruning is performed before `SELECT` column privileges are checked. For example, executing `SELECT a FROM (SELECT a, b FROM t) s` only requires the `SELECT` column privilege on `t.a`. | |
| 121 | + |
| 122 | +### Column pruning and privilege checks in view scenarios |
| 123 | + |
| 124 | +When performing `SELECT` privilege checks on views, MySQL and TiDB differ as follows: |
| 125 | + |
| 126 | +- MySQL first prunes columns in the view's internal query and then checks the column privileges of the internal tables, making the checks relatively lenient in some scenarios. |
| 127 | +- TiDB does not perform column pruning before privilege checks, so additional column privileges might be required. |
| 128 | + |
| 129 | +```sql |
| 130 | +-- Prepare the environment by logging in as root |
| 131 | +DROP USER IF EXISTS 'u'@'%'; |
| 132 | +CREATE USER 'u'@'%'; |
| 133 | + |
| 134 | +DROP TABLE IF EXISTS t; |
| 135 | +CREATE TABLE t (a INT, b INT, c INT, d INT); |
| 136 | + |
| 137 | +DROP VIEW IF EXISTS v; |
| 138 | +CREATE SQL SECURITY INVOKER VIEW v AS SELECT a, b FROM t WHERE c = 0 ORDER BY d; |
| 139 | + |
| 140 | +GRANT SELECT ON v TO 'u'@'%'; |
| 141 | + |
| 142 | +-- Log in as u |
| 143 | +SELECT a FROM v; |
| 144 | +-- MySQL: Error, missing access privileges for t.a, t.c, t.d |
| 145 | +-- TiDB: Error, missing access privileges for t.a, t.b, t.c, t.d |
| 146 | + |
| 147 | +-- Log in as root |
| 148 | +GRANT SELECT(a, c, d) ON t TO 'u'@'%'; |
| 149 | + |
| 150 | +-- Log in as u |
| 151 | +SELECT a FROM v; |
| 152 | +-- MySQL: Success (internal query is pruned to `SELECT a FROM t WHERE c = 0 ORDER BY d`) |
| 153 | +-- TiDB: Error, missing access privileges for t.b |
| 154 | + |
| 155 | +SELECT * FROM v; |
| 156 | +-- MySQL: Error, missing access privileges for t.b |
| 157 | +-- TiDB: Error, missing access privileges for t.b |
| 158 | + |
| 159 | +-- Log in as root |
| 160 | +GRANT SELECT(b) ON t TO 'u'@'%'; |
| 161 | + |
| 162 | +-- Log in as u |
| 163 | +SELECT * FROM v; |
| 164 | +-- MySQL: Success |
| 165 | +-- TiDB: Success |
| 166 | +``` |
| 167 | + |
| 168 | +## See also |
| 169 | + |
| 170 | +* [Privilege Management](/privilege-management.md) |
| 171 | +* [`GRANT <privileges>`](/sql-statements/sql-statement-grant-privileges.md) |
| 172 | +* [`REVOKE <privileges>`](/sql-statements/sql-statement-revoke-privileges.md) |
0 commit comments