mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-10 09:32:06 +00:00
DOCS-626: EN review, RU translations for RBAC docs (#10951)
* DOCSUP-1062 (#112) * added first draft * minor fixes * fixed anchors * yet another fixes * and the minorest fixes * Apply suggestions from doc review Co-authored-by: BayoNet <da-daos@yandex.ru> * fixed terminology in ru (access entity, throws exception) * fixed typo * fixed typo Co-authored-by: Elizaveta Mironyuk <emironyuk@yandex-team.ru> Co-authored-by: BayoNet <da-daos@yandex.ru> * Fixed link. * CLICKHOUSEDOCS-626: Fixed links. Co-authored-by: Sergei Shtykov <bayonet@yandex-team.ru> Co-authored-by: emironyuk <62014692+emironyuk@users.noreply.github.com> Co-authored-by: Elizaveta Mironyuk <emironyuk@yandex-team.ru>
This commit is contained in:
parent
cc4ddfd89e
commit
c701493e30
@ -22,7 +22,7 @@ You can configure access entities using:
|
||||
|
||||
- Server [configuration files](configuration-files.md) `users.xml` and `config.xml`.
|
||||
|
||||
We recommend using SQL-driven workflow. Both of the configuration methods work simultaneously, so if you use the server configuration files for managing accounts and access rights, you can softly move to SQL-driven workflow.
|
||||
We recommend using SQL-driven workflow. Both of the configuration methods work simultaneously, so if you use the server configuration files for managing accounts and access rights, you can smoothly switch to SQL-driven workflow.
|
||||
|
||||
!!! note "Warning"
|
||||
You can't manage the same access entity by both configuration methods simultaneously.
|
||||
@ -30,32 +30,32 @@ We recommend using SQL-driven workflow. Both of the configuration methods work s
|
||||
|
||||
## Usage {#access-control-usage}
|
||||
|
||||
By default, the ClickHouse server provides the user account `default` which is not allowed using SQL-driven access control and account management but have all the rights and permissions. The `default` user account is used in any cases when the username is not defined, for example, at login from client or in distributed queries. In distributed query processing a default user account is used, if the configuration of the server or cluster doesn’t specify the [user and password](../engines/table-engines/special/distributed.md) properties.
|
||||
By default, the ClickHouse server provides the `default` user account which is not allowed using SQL-driven access control and account management but has all the rights and permissions. The `default` user account is used in any cases when the username is not defined, for example, at login from client or in distributed queries. In distributed query processing a default user account is used, if the configuration of the server or cluster doesn’t specify the [user and password](../engines/table-engines/special/distributed.md) properties.
|
||||
|
||||
If you just start using ClickHouse, you can use the following scenario:
|
||||
If you just started using ClickHouse, consider the following scenario:
|
||||
|
||||
1. [Enable](#enabling-access-control) SQL-driven access control and account management for the `default` user.
|
||||
2. Login under the `default` user account and create all the required users. Don't forget to create an administrator account (`GRANT ALL ON *.* WITH GRANT OPTION TO admin_user_account`).
|
||||
2. Log in to the `default` user account and create all the required users. Don't forget to create an administrator account (`GRANT ALL ON *.* WITH GRANT OPTION TO admin_user_account`).
|
||||
3. [Restrict permissions](settings/permissions-for-queries.md#permissions_for_queries) for the `default` user and disable SQL-driven access control and account management for it.
|
||||
|
||||
### Properties of Current Solution {#access-control-properties}
|
||||
|
||||
- You can grant permissions for databases and tables even if they are not exist.
|
||||
- If a table was deleted, all the privileges that correspond to this table are not revoked. So, if a new table is created later with the same name all the privileges become again actual. To revoke privileges corresponding to the deleted table, you need to perform, for example, the `REVOKE ALL PRIVILEGES ON db.table FROM ALL` query.
|
||||
- There is no lifetime settings for privileges.
|
||||
- You can grant permissions for databases and tables even if they do not exist.
|
||||
- If a table was deleted, all the privileges that correspond to this table are not revoked. This means that even if you create a new table with the same name later, all the privileges remain valid. To revoke privileges corresponding to the deleted table, you need to execute, for example, the `REVOKE ALL PRIVILEGES ON db.table FROM ALL` query.
|
||||
- There are no lifetime settings for privileges.
|
||||
|
||||
## User account {#user-account-management}
|
||||
|
||||
A user account is an access entity that allows to authorize someone in ClickHouse. A user account contains:
|
||||
|
||||
- Identification information.
|
||||
- [Privileges](../sql-reference/statements/grant.md#grant-privileges) that define a scope of queries the user can perform.
|
||||
- Hosts from which connection to the ClickHouse server is allowed.
|
||||
- Granted and default roles.
|
||||
- Settings with their constraints that apply by default at the user's login.
|
||||
- [Privileges](../sql-reference/statements/grant.md#grant-privileges) that define a scope of queries the user can execute.
|
||||
- Hosts allowed to connect to the ClickHouse server.
|
||||
- Assigned and default roles.
|
||||
- Settings with their constraints applied by default at user login.
|
||||
- Assigned settings profiles.
|
||||
|
||||
Privileges to a user account can be granted by the [GRANT](../sql-reference/statements/grant.md) query or by assigning [roles](#role-management). To revoke privileges from a user, ClickHouse provides the [REVOKE](../sql-reference/statements/revoke.md) query. To list privileges for a user, use the - [SHOW GRANTS](../sql-reference/statements/show.md#show-grants-statement) statement.
|
||||
Privileges can be granted to a user account by the [GRANT](../sql-reference/statements/grant.md) query or by assigning [roles](#role-management). To revoke privileges from a user, ClickHouse provides the [REVOKE](../sql-reference/statements/revoke.md) query. To list privileges for a user, use the [SHOW GRANTS](../sql-reference/statements/show.md#show-grants-statement) statement.
|
||||
|
||||
Management queries:
|
||||
|
||||
@ -66,11 +66,11 @@ Management queries:
|
||||
|
||||
### Settings Applying {#access-control-settings-applying}
|
||||
|
||||
Settings can be set by different ways: for a user account, in its granted roles and settings profiles. At a user login, if a setting is set in different access entities, the value and constrains of this setting are applied by the following priorities (from higher to lower):
|
||||
Settings can be configured differently: for a user account, in its granted roles and in settings profiles. At user login, if a setting is configured for different access entities, the value and constraints of this setting are applied as follows (from higher to lower priority):
|
||||
|
||||
1. User account setting.
|
||||
2. The settings of default roles of the user account. If a setting is set in some roles, then order of the setting applying is undefined.
|
||||
3. The settings in settings profiles assigned to a user or to its default roles. If a setting is set in some profiles, then order of setting applying is undefined.
|
||||
1. User account settings.
|
||||
2. The settings of default roles of the user account. If a setting is configured in some roles, then order of the setting application is undefined.
|
||||
3. The settings from settings profiles assigned to a user or to its default roles. If a setting is configured in some profiles, then order of setting application is undefined.
|
||||
4. Settings applied to all the server by default or from the [default profile](server-configuration-parameters/settings.md#default-profile).
|
||||
|
||||
|
||||
@ -82,7 +82,7 @@ Role contains:
|
||||
|
||||
- [Privileges](../sql-reference/statements/grant.md#grant-privileges)
|
||||
- Settings and constraints
|
||||
- List of granted roles
|
||||
- List of assigned roles
|
||||
|
||||
Management queries:
|
||||
|
||||
@ -93,11 +93,11 @@ Management queries:
|
||||
- [SET DEFAULT ROLE](../sql-reference/statements/misc.md#set-default-role-statement)
|
||||
- [SHOW CREATE ROLE](../sql-reference/statements/show.md#show-create-role-statement)
|
||||
|
||||
Privileges to a role can be granted by the [GRANT](../sql-reference/statements/grant.md) query. To revoke privileges from a role ClickHouse provides the [REVOKE](../sql-reference/statements/revoke.md) query.
|
||||
Privileges can be granted to a role by the [GRANT](../sql-reference/statements/grant.md) query. To revoke privileges from a role ClickHouse provides the [REVOKE](../sql-reference/statements/revoke.md) query.
|
||||
|
||||
## Row Policy {#row-policy-management}
|
||||
|
||||
Row policy is a filter that defines which or rows is available for a user or for a role. Row policy contains filters for one specific table and list of roles and/or users which should use this row policy.
|
||||
Row policy is a filter that defines which of the rows are available to a user or a role. Row policy contains filters for one particular table, as well as a list of roles and/or users which should use this row policy.
|
||||
|
||||
Management queries:
|
||||
|
||||
@ -109,7 +109,7 @@ Management queries:
|
||||
|
||||
## Settings Profile {#settings-profiles-management}
|
||||
|
||||
Settings profile is a collection of [settings](settings/index.md). Settings profile contains settings and constraints, and list of roles and/or users to which this quota is applied.
|
||||
Settings profile is a collection of [settings](settings/index.md). Settings profile contains settings and constraints, as well as a list of roles and/or users to which this profile is applied.
|
||||
|
||||
Management queries:
|
||||
|
||||
@ -123,7 +123,7 @@ Management queries:
|
||||
|
||||
Quota limits resource usage. See [Quotas](quotas.md).
|
||||
|
||||
Quota contains a set of limits for some durations, and list of roles and/or users which should use this quota.
|
||||
Quota contains a set of limits for some durations, as well as a list of roles and/or users which should use this quota.
|
||||
|
||||
Management queries:
|
||||
|
||||
@ -141,7 +141,7 @@ Management queries:
|
||||
|
||||
- Enable SQL-driven access control and account management for at least one user account.
|
||||
|
||||
By default, SQL-driven access control and account management is turned off for all users. You need to configure at least one user in the `users.xml` configuration file and assign 1 to the [access_management](settings/settings-users.md#access_management-user-setting) setting.
|
||||
By default, SQL-driven access control and account management is disabled for all users. You need to configure at least one user in the `users.xml` configuration file and set the value of the [access_management](settings/settings-users.md#access_management-user-setting) setting to 1.
|
||||
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/operations/access_rights/) <!--hide-->
|
||||
|
@ -11,7 +11,7 @@ A settings profile is a collection of settings grouped under the same name.
|
||||
ClickHouse also supports [SQL-driven workflow](../access-rights.md#access-control) for managing settings profiles. We recommend using it.
|
||||
|
||||
|
||||
A profile can have any name. The profile can have any name. You can specify the same profile for different users. The most important thing you can write in the settings profile is `readonly=1`, which ensures read-only access.
|
||||
The profile can have any name. You can specify the same profile for different users. The most important thing you can write in the settings profile is `readonly=1`, which ensures read-only access.
|
||||
|
||||
Settings profiles can inherit from each other. To use inheritance, indicate one or multiple `profile` settings before the other settings that are listed in the profile. In case when one setting is defined in different profiles, the latest defined is used.
|
||||
|
||||
|
@ -76,7 +76,7 @@ Password can be specified in plaintext or in SHA256 (hex format).
|
||||
|
||||
### access_management {#access_management-user-setting}
|
||||
|
||||
This setting enables of disables using of SQL-driven [access control and account management](../access-rights.md#access-control) for the user.
|
||||
This setting enables or disables using of SQL-driven [access control and account management](../access-rights.md#access-control) for the user.
|
||||
|
||||
Possible values:
|
||||
|
||||
|
@ -520,23 +520,23 @@ To use `ALTER USER` you must have the [ALTER USER](grant.md#grant-access-managem
|
||||
|
||||
### Examples {#alter-user-examples}
|
||||
|
||||
Set granted roles as default:
|
||||
Set assigned roles as default:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE role1, role2
|
||||
```
|
||||
|
||||
If roles aren't previously granted to a user, ClickHouse throws an exception.
|
||||
If roles aren't previously assigned to a user, ClickHouse throws an exception.
|
||||
|
||||
Set all the granted roles to default:
|
||||
Set all the assigned roles to default:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE ALL
|
||||
```
|
||||
|
||||
If a role will be granted to a user in the future it will become default automatically.
|
||||
If a role is assigned to a user in the future, it will become default automatically.
|
||||
|
||||
Set all the granted roles to default excepting `role1` and `role2`:
|
||||
Set all the assigned roles to default, excepting `role1` and `role2`:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2
|
||||
@ -591,7 +591,7 @@ ALTER QUOTA [IF EXISTS] name [ON CLUSTER cluster_name]
|
||||
|
||||
## ALTER SETTINGS PROFILE {#alter-settings-profile-statement}
|
||||
|
||||
Changes quotas.
|
||||
Changes settings profiles.
|
||||
|
||||
### Syntax {#alter-settings-profile-syntax}
|
||||
|
||||
|
@ -327,23 +327,23 @@ There are multiple ways of user identification:
|
||||
|
||||
#### User Host
|
||||
|
||||
User host is a host from which a connection to ClickHouse server could be established. Host can be specified in the `HOST` section of query by the following ways:
|
||||
User host is a host from which a connection to ClickHouse server could be established. The host can be specified in the `HOST` query section in the following ways:
|
||||
|
||||
- `HOST IP 'ip_address_or_subnetwork'` — User can connect to ClickHouse server only from the specified IP address or a [subnetwork](https://en.wikipedia.org/wiki/Subnetwork). Examples: `HOST IP '192.168.0.0/16'`, `HOST IP '2001:DB8::/32'`. For use in production, only specify `HOST IP` elements (IP addresses and their masks), since using `host` and `host_regexp` might cause extra latency.
|
||||
- `HOST ANY` — User can connect from any location. This is default option.
|
||||
- `HOST ANY` — User can connect from any location. This is a default option.
|
||||
- `HOST LOCAL` — User can connect only locally.
|
||||
- `HOST NAME 'fqdn'` — User host can be specified as FQDN. For example, `HOST NAME 'mysite.com'`.
|
||||
- `HOST NAME REGEXP 'regexp'` — You can use [pcre](http://www.pcre.org/) regular expressions when specifying user hosts. For example, `HOST NAME REGEXP '.*\.mysite\.com'`.
|
||||
- `HOST LIKE 'template'` — Allows you use the [LIKE](../functions/string-search-functions.md#function-like) operator to filter the user hosts. For example, `HOST LIKE '%'` is equivalent to `HOST ANY`, `HOST LIKE '%.mysite.com'` filters all the hosts in the `mysite.com` domain.
|
||||
- `HOST LIKE 'template'` — Allows you to use the [LIKE](../functions/string-search-functions.md#function-like) operator to filter the user hosts. For example, `HOST LIKE '%'` is equivalent to `HOST ANY`, `HOST LIKE '%.mysite.com'` filters all the hosts in the `mysite.com` domain.
|
||||
|
||||
Another way of specifying host is to use `@` syntax with the user name. Examples:
|
||||
Another way of specifying host is to use `@` syntax following the username. Examples:
|
||||
|
||||
- `CREATE USER mira@'127.0.0.1'` — Equivalent to the `HOST IP` syntax.
|
||||
- `CREATE USER mira@'localhost'` — Equivalent to the `HOST LOCAL` syntax.
|
||||
- `CREATE USER mira@'192.168.%.%'` — Equivalent to the `HOST LIKE` syntax.
|
||||
|
||||
!!! info "Warning"
|
||||
ClickHouse treats `user_name@'address'` as a user name as a whole. Thus, technically you can create multiple users with `user_name` and different constructions after `@`. We don't recommend to do so.
|
||||
ClickHouse treats `user_name@'address'` as a username as a whole. Thus, technically you can create multiple users with the same `user_name` and different constructions after `@`. However, we don't recommend to do so.
|
||||
|
||||
|
||||
### Examples {#create-user-examples}
|
||||
@ -369,7 +369,7 @@ Create the user account `john` and make all his future roles default:
|
||||
ALTER USER user DEFAULT ROLE ALL
|
||||
```
|
||||
|
||||
When some role will be assigned to `john` in the future it will become default automatically.
|
||||
When some role is assigned to `john` in the future, it will become default automatically.
|
||||
|
||||
Create the user account `john` and make all his future roles default excepting `role1` and `role2`:
|
||||
|
||||
@ -391,15 +391,15 @@ CREATE ROLE [IF NOT EXISTS | OR REPLACE] name
|
||||
|
||||
### Description {#create-role-description}
|
||||
|
||||
Role is a set of [privileges](grant.md#grant-privileges). A user granted with a role gets all the privileges of this role.
|
||||
Role is a set of [privileges](grant.md#grant-privileges). A user assigned a role gets all the privileges of this role.
|
||||
|
||||
A user can be assigned with multiple roles. Users can apply their granted roles in arbitrary combinations by the [SET ROLE](misc.md#set-role-statement) statement. The final scope of privileges is a combined set of all the privileges of all the applied roles. If a user has privileges granted directly to it's user account, they are also combined with the privileges granted by roles.
|
||||
A user can be assigned multiple roles. Users can apply their assigned roles in arbitrary combinations by the [SET ROLE](misc.md#set-role-statement) statement. The final scope of privileges is a combined set of all the privileges of all the applied roles. If a user has privileges granted directly to it's user account, they are also combined with the privileges granted by roles.
|
||||
|
||||
User can have default roles which apply at user login. To set default roles, use the [SET DEFAULT ROLE](misc.md#set-default-role-statement) statement or the [ALTER USER](alter.md#alter-user-statement) statement.
|
||||
|
||||
To revoke a role, use the [REVOKE](revoke.md) statement.
|
||||
|
||||
To delete role, use the [DROP ROLE](misc.md#drop-role-statement) statement. The deleted role is being automatically revoked from all the users and roles to which it was granted.
|
||||
To delete role, use the [DROP ROLE](misc.md#drop-role-statement) statement. The deleted role is being automatically revoked from all the users and roles to which it was assigned.
|
||||
|
||||
### Examples {#create-role-examples}
|
||||
|
||||
@ -410,13 +410,13 @@ GRANT SELECT ON db.* TO accountant;
|
||||
|
||||
This sequence of queries creates the role `accountant` that has the privilege of reading data from the `accounting` database.
|
||||
|
||||
Granting the role to the user `mira`:
|
||||
Assigning the role to the user `mira`:
|
||||
|
||||
```sql
|
||||
GRANT accountant TO mira;
|
||||
```
|
||||
|
||||
After the role is granted, the user can use it and perform the allowed queries. For example:
|
||||
After the role is assigned, the user can apply it and execute the allowed queries. For example:
|
||||
|
||||
```sql
|
||||
SET ROLE accountant;
|
||||
@ -443,15 +443,15 @@ Using this section you can create permissive or restrictive policies.
|
||||
|
||||
Permissive policy grants access to rows. Permissive policies which apply to the same table are combined together using the boolean `OR` operator. Policies are permissive by default.
|
||||
|
||||
Restrictive policy restricts access to row. Restrictive policies which apply to the same table are combined together using the boolean `AND` operator.
|
||||
Restrictive policy restricts access to rows. Restrictive policies which apply to the same table are combined together using the boolean `AND` operator.
|
||||
|
||||
Restrictive policies apply to rows that passed the permissive filters. If you set restrictive policies but no permissive policies, the user can't get any row from the table.
|
||||
|
||||
#### Section TO {#create-row-policy-to}
|
||||
|
||||
In the section `TO` you can give a mixed list of roles and users, for example, `CREATE ROW POLICY ... TO accountant, john@localhost`.
|
||||
In the section `TO` you can provide a mixed list of roles and users, for example, `CREATE ROW POLICY ... TO accountant, john@localhost`.
|
||||
|
||||
Keyword `ALL` means all the ClickHouse users including current user. Keywords `ALL EXCEPT` allow to to exclude some users from the all users list, for example `CREATE ROW POLICY ... TO ALL EXCEPT accountant, john@localhost`
|
||||
Keyword `ALL` means all the ClickHouse users including current user. Keywords `ALL EXCEPT` allow to exclude some users from the all users list, for example, `CREATE ROW POLICY ... TO ALL EXCEPT accountant, john@localhost`
|
||||
|
||||
### Examples
|
||||
|
||||
@ -494,7 +494,7 @@ CREATE SETTINGS PROFILE [IF NOT EXISTS | OR REPLACE] name [ON CLUSTER cluster_na
|
||||
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE] | INHERIT 'profile_name'] [,...]
|
||||
```
|
||||
|
||||
# Example {#create-settings-profile-syntax}
|
||||
### Example {#create-settings-profile-syntax}
|
||||
|
||||
Create the `max_memory_usage_profile` settings profile with value and constraints for the `max_memory_usage` setting. Assign it to `robin`:
|
||||
|
||||
|
@ -7,9 +7,9 @@ toc_title: GRANT
|
||||
# GRANT
|
||||
|
||||
- Grants [privileges](#grant-privileges) to ClickHouse user accounts or roles.
|
||||
- Assigns roles to user accounts or to another roles.
|
||||
- Assigns roles to user accounts or to the other roles.
|
||||
|
||||
To revoke privileges, use the [REVOKE](revoke.md) statement. Also you can list granted privileges by the [SHOW GRANTS](show.md#show-grants-statement) statement.
|
||||
To revoke privileges, use the [REVOKE](revoke.md) statement. Also you can list granted privileges with the [SHOW GRANTS](show.md#show-grants-statement) statement.
|
||||
|
||||
## Granting Privilege Syntax {#grant-privigele-syntax}
|
||||
|
||||
@ -21,10 +21,10 @@ GRANT [ON CLUSTER cluster_name] privilege[(column_name [,...])] [,...] ON {db.ta
|
||||
- `role` — ClickHouse user role.
|
||||
- `user` — ClickHouse user account.
|
||||
|
||||
The `WITH GRANT OPTION` clause grants `user` or `role` with permission to perform the `GRANT` query. Users can grant privileges of the same scope they have and less.
|
||||
The `WITH GRANT OPTION` clause grants `user` or `role` with permission to execute the `GRANT` query. Users can grant privileges of the same scope they have and less.
|
||||
|
||||
|
||||
## Granting Role Syntax {#assign-role-syntax}
|
||||
## Assigning Role Syntax {#assign-role-syntax}
|
||||
|
||||
```sql
|
||||
GRANT [ON CLUSTER cluster_name] role [,...] TO {user | another_role | CURRENT_USER} [,...] [WITH ADMIN OPTION]
|
||||
@ -33,7 +33,7 @@ GRANT [ON CLUSTER cluster_name] role [,...] TO {user | another_role | CURRENT_US
|
||||
- `role` — ClickHouse user role.
|
||||
- `user` — ClickHouse user account.
|
||||
|
||||
The `WITH ADMIN OPTION` clause sets [ADMIN OPTION](#admin-option-privilege) privilege for `user` or `role`.
|
||||
The `WITH ADMIN OPTION` clause grants [ADMIN OPTION](#admin-option-privilege) privilege to `user` or `role`.
|
||||
|
||||
## Usage {#grant-usage}
|
||||
|
||||
@ -45,28 +45,28 @@ For example, administrator has granted privileges to the `john` account by the q
|
||||
GRANT SELECT(x,y) ON db.table TO john WITH GRANT OPTION
|
||||
```
|
||||
|
||||
It means that `john` has the permission to perform:
|
||||
It means that `john` has the permission to execute:
|
||||
|
||||
- `SELECT x,y FROM db.table`.
|
||||
- `SELECT x FROM db.table`.
|
||||
- `SELECT y FROM db.table`.
|
||||
|
||||
`john` can't perform `SELECT z FROM db.table`. The `SELECT * FROM db.table` also is not available. Processing this query, ClickHouse doesn't return any data, even `x` and `y`. The only exception is if a table contains only `x` and `y` columns, in this case ClickHouse returns all the data.
|
||||
`john` can't execute `SELECT z FROM db.table`. The `SELECT * FROM db.table` also is not available. Processing this query, ClickHouse doesn't return any data, even `x` and `y`. The only exception is if a table contains only `x` and `y` columns. In this case ClickHouse returns all the data.
|
||||
|
||||
Also `john` has the `GRANT OPTION` privilege, so it can grant other users with privileges of the same or the smaller scope.
|
||||
Also `john` has the `GRANT OPTION` privilege, so it can grant other users with privileges of the same or smaller scope.
|
||||
|
||||
Specifying privileges you can use asterisk (`*`) instead of a table or a database name. For example, the `GRANT SELECT ON db.* TO john` query allows `john` to perform the `SELECT` query over all the tables in `db` database. Also, you can omit database name. In this case privileges are granted for current database, for example: `GRANT SELECT ON * TO john` grants the privilege on all the tables in the current database, `GRANT SELECT ON mytable TO john` grants the privilege on the `mytable` table in the current database.
|
||||
Specifying privileges you can use asterisk (`*`) instead of a table or a database name. For example, the `GRANT SELECT ON db.* TO john` query allows `john` to execute the `SELECT` query over all the tables in `db` database. Also, you can omit database name. In this case privileges are granted for current database. For example, `GRANT SELECT ON * TO john` grants the privilege on all the tables in the current database, `GRANT SELECT ON mytable TO john` grants the privilege on the `mytable` table in the current database.
|
||||
|
||||
Access to the `system` database is always allowed (since this database is used for processing queries).
|
||||
|
||||
You can grant multiple privileges to multiple accounts in one query. The query `GRANT SELECT, INSERT ON *.* TO john, robin` allows accounts `john` and `robin` to perform the `INSERT` and `SELECT` queries over all the tables in all the databases on the server.
|
||||
You can grant multiple privileges to multiple accounts in one query. The query `GRANT SELECT, INSERT ON *.* TO john, robin` allows accounts `john` and `robin` to execute the `INSERT` and `SELECT` queries over all the tables in all the databases on the server.
|
||||
|
||||
|
||||
## Privileges {#grant-privileges}
|
||||
|
||||
Privilege is a permission to perform specific kind of queries.
|
||||
Privilege is a permission to execute specific kind of queries.
|
||||
|
||||
Privileges have an hierarchical structure. A set of permitted queries depends on the privilege scope.
|
||||
Privileges have a hierarchical structure. A set of permitted queries depends on the privilege scope.
|
||||
|
||||
Hierarchy of privileges:
|
||||
|
||||
@ -212,20 +212,20 @@ The special privilege [ALL](#grant-all) grants all the privileges to a user acco
|
||||
|
||||
By default, a user account or a role has no privileges.
|
||||
|
||||
If a user or role have no privileges it displayed as [NONE](#grant-none) privilege.
|
||||
If a user or a role has no privileges, it is displayed as [NONE](#grant-none) privilege.
|
||||
|
||||
Some queries by their implementation require a set of privileges. For example, to perform the [RENAME](misc.md#misc_operations-rename) query you need the following privileges: `SELECT`, `CREATE TABLE`, `INSERT` and `DROP TABLE`.
|
||||
Some queries by their implementation require a set of privileges. For example, to execute the [RENAME](misc.md#misc_operations-rename) query you need the following privileges: `SELECT`, `CREATE TABLE`, `INSERT` and `DROP TABLE`.
|
||||
|
||||
|
||||
### SELECT {#grant-select}
|
||||
|
||||
Allows to perform [SELECT](select/index.md) queries.
|
||||
Allows executing [SELECT](select/index.md) queries.
|
||||
|
||||
Privilege level: `COLUMN`.
|
||||
|
||||
**Description**
|
||||
|
||||
User granted with this privilege can perform `SELECT` queries over a specified list of columns in the specified table and database. If user includes other columns then specified a query returns no data.
|
||||
User granted with this privilege can execute `SELECT` queries over a specified list of columns in the specified table and database. If user includes other columns then specified a query returns no data.
|
||||
|
||||
Consider the following privilege:
|
||||
|
||||
@ -233,17 +233,17 @@ Consider the following privilege:
|
||||
GRANT SELECT(x,y) ON db.table TO john
|
||||
```
|
||||
|
||||
This privilege allows `john` to perform any `SELECT` query that involves data from the `x` and/or `y` columns in `db.table`. For example, `SELECT x FROM db.table`. `john` can't perform `SELECT z FROM db.table`. The `SELECT * FROM db.table` also is not available. Processing this query, ClickHouse doesn't return any data, even `x` and `y`. The only exception is if a table contains only `x` and `y` columns, in this case ClickHouse returns all the data.
|
||||
This privilege allows `john` to execute any `SELECT` query that involves data from the `x` and/or `y` columns in `db.table`, for example, `SELECT x FROM db.table`. `john` can't execute `SELECT z FROM db.table`. The `SELECT * FROM db.table` also is not available. Processing this query, ClickHouse doesn't return any data, even `x` and `y`. The only exception is if a table contains only `x` and `y` columns, in this case ClickHouse returns all the data.
|
||||
|
||||
### INSERT {#grant-insert}
|
||||
|
||||
Allows performing [INSERT](insert-into.md) queries.
|
||||
Allows executing [INSERT](insert-into.md) queries.
|
||||
|
||||
Privilege level: `COLUMN`.
|
||||
|
||||
**Description**
|
||||
|
||||
User granted with this privilege can perform `INSERT` queries over a specified list of columns in the specified table and database. If user includes other columns then specified a query doesn't insert any data.
|
||||
User granted with this privilege can execute `INSERT` queries over a specified list of columns in the specified table and database. If user includes other columns then specified a query doesn't insert any data.
|
||||
|
||||
**Example**
|
||||
|
||||
@ -255,7 +255,7 @@ The granted privilege allows `john` to insert data to the `x` and/or `y` columns
|
||||
|
||||
### ALTER {#grant-alter}
|
||||
|
||||
Allows performing [ALTER](alter.md) queries corresponding to the following hierarchy of privileges:
|
||||
Allows executing [ALTER](alter.md) queries according to the following hierarchy of privileges:
|
||||
|
||||
- `ALTER`. Level: `COLUMN`.
|
||||
- `ALTER TABLE`. Level: `GROUP`
|
||||
@ -294,14 +294,14 @@ Examples of how this hierarchy is treated:
|
||||
|
||||
**Notes**
|
||||
|
||||
- The `MODIFY SETTING` privilege allows to modify table engine settings. In doesn't affect settings or server configuration parameters.
|
||||
- The `MODIFY SETTING` privilege allows modifying table engine settings. It doesn't affect settings or server configuration parameters.
|
||||
- The `ATTACH` operation needs the [CREATE](#grant-create) privilege.
|
||||
- The `DETACH` operation needs the [DROP](#grant-drop) privilege.
|
||||
- To stop mutation by the [KILL MUTATION](misc.md#kill-mutation) query, you need to have a privilege to start this mutation. For example, if you want to stop the `ALTER UPDATE` query, you need the `ALTER UPDATE`, `ALTER TABLE`, or `ALTER` privilege.
|
||||
|
||||
### CREATE {#grant-create}
|
||||
|
||||
Allows to perform [CREATE](create.md) and [ATTACH](misc.md#attach) DDL-queries corresponding to the following hierarchy of privileges:
|
||||
Allows executing [CREATE](create.md) and [ATTACH](misc.md#attach) DDL-queries according to the following hierarchy of privileges:
|
||||
|
||||
- `CREATE`. Level: `GROUP`
|
||||
- `CREATE DATABASE`. Level: `DATABASE`
|
||||
@ -316,7 +316,7 @@ Allows to perform [CREATE](create.md) and [ATTACH](misc.md#attach) DDL-queries c
|
||||
|
||||
### DROP {#grant-drop}
|
||||
|
||||
Allows to perform [DROP](misc.md#drop) and [DETACH](misc.md#detach) queries corresponding to the following hierarchy of privileges:
|
||||
Allows executing [DROP](misc.md#drop) and [DETACH](misc.md#detach) queries according to the following hierarchy of privileges:
|
||||
|
||||
- `DROP`. Level:
|
||||
- `DROP DATABASE`. Level: `DATABASE`
|
||||
@ -327,19 +327,19 @@ Allows to perform [DROP](misc.md#drop) and [DETACH](misc.md#detach) queries corr
|
||||
|
||||
### TRUNCATE {#grant-truncate}
|
||||
|
||||
Allows to perform [TRUNCATE](misc.md#truncate-statement) queries.
|
||||
Allows executing [TRUNCATE](misc.md#truncate-statement) queries.
|
||||
|
||||
Privilege level: `TABLE`.
|
||||
|
||||
### OPTIMIZE {#grant-optimize}
|
||||
|
||||
Allows to perform the [OPTIMIZE TABLE](misc.md#misc_operations-optimize) queries.
|
||||
Allows executing [OPTIMIZE TABLE](misc.md#misc_operations-optimize) queries.
|
||||
|
||||
Privilege level: `TABLE`.
|
||||
|
||||
### SHOW {#grant-show}
|
||||
|
||||
Allows to perform `SHOW`, `DESCRIBE`, `USE`, and `EXISTS` queries, corresponding to the following hierarchy of privileges:
|
||||
Allows executing `SHOW`, `DESCRIBE`, `USE`, and `EXISTS` queries according to the following hierarchy of privileges:
|
||||
|
||||
- `SHOW`. Level: `GROUP`
|
||||
- `SHOW DATABASES`. Level: `DATABASE`. Allows to execute `SHOW DATABASES`, `SHOW CREATE DATABASE`, `USE <database>` queries.
|
||||
@ -349,12 +349,12 @@ Allows to perform `SHOW`, `DESCRIBE`, `USE`, and `EXISTS` queries, corresponding
|
||||
|
||||
**Notes**
|
||||
|
||||
A user has the `SHOW` privilege if it has any another privilege concerning the specified table, dictionary or database.
|
||||
A user has the `SHOW` privilege if it has any other privilege concerning the specified table, dictionary or database.
|
||||
|
||||
|
||||
### KILL QUERY {#grant-kill-query}
|
||||
|
||||
Allows to perform the [KILL](misc.md#kill-query-statement) queries corresponding to the following hierarchy of privileges:
|
||||
Allows executing [KILL](misc.md#kill-query-statement) queries according to the following hierarchy of privileges:
|
||||
|
||||
Privilege level: `GLOBAL`.
|
||||
|
||||
@ -365,7 +365,7 @@ Privilege level: `GLOBAL`.
|
||||
|
||||
### ACCESS MANAGEMENT {#grant-access-management}
|
||||
|
||||
Allows a user to perform queries that manage users, roles and row policies.
|
||||
Allows a user to execute queries that manage users, roles and row policies.
|
||||
|
||||
- `ACCESS MANAGEMENT`. Level: `GROUP`
|
||||
- `CREATE USER`. Level: `GLOBAL`
|
||||
@ -391,11 +391,11 @@ Allows a user to perform queries that manage users, roles and row policies.
|
||||
- `SHOW_QUOTAS`. Level: `GLOBAL`. Aliases: `SHOW CREATE QUOTA`
|
||||
- `SHOW_SETTINGS_PROFILES`. Level: `GLOBAL`. Aliases: `SHOW PROFILES`, `SHOW CREATE SETTINGS PROFILE`, `SHOW CREATE PROFILE`
|
||||
|
||||
The `ROLE ADMIN` privilege allows a user to grant and revoke any roles including those which are not granted to the user with the admin option.
|
||||
The `ROLE ADMIN` privilege allows a user to assign and revoke any roles including those which are not assigned to the user with the admin option.
|
||||
|
||||
### SYSTEM {#grant-system}
|
||||
|
||||
Allows a user to perform the [SYSTEM](system.md) queries corresponding to the following hierarchy of privileges.
|
||||
Allows a user to execute [SYSTEM](system.md) queries according to the following hierarchy of privileges.
|
||||
|
||||
- `SYSTEM`. Level: `GROUP`
|
||||
- `SYSTEM SHUTDOWN`. Level: `GLOBAL`. Aliases: `SYSTEM KILL`, `SHUTDOWN`
|
||||
@ -461,7 +461,7 @@ Examples:
|
||||
|
||||
Allows a user to execute [dictGet](../functions/ext-dict-functions.md#dictget), [dictHas](../functions/ext-dict-functions.md#dicthas), [dictGetHierarchy](../functions/ext-dict-functions.md#dictgethierarchy), [dictIsIn](../functions/ext-dict-functions.md#dictisin) functions.
|
||||
|
||||
Level of privilege: `DICTIONARY`.
|
||||
Privilege level: `DICTIONARY`.
|
||||
|
||||
**Examples**
|
||||
|
||||
@ -480,6 +480,6 @@ Doesn't grant any privileges.
|
||||
|
||||
### ADMIN OPTION {#admin-option-privilege}
|
||||
|
||||
The `ADMIN OPTION` privilege allows a user granting their role to another user.
|
||||
The `ADMIN OPTION` privilege allows a user to grant their role to another user.
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/query_language/grant/) <!--hide-->
|
||||
|
@ -126,7 +126,7 @@ DROP USER [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
|
||||
Deletes a role.
|
||||
|
||||
Deleted role is revoked from all the entities where it was granted.
|
||||
Deleted role is revoked from all the entities where it was assigned.
|
||||
|
||||
### Syntax {#drop-role-syntax}
|
||||
|
||||
@ -162,9 +162,9 @@ DROP QUOTA [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
|
||||
## DROP SETTINGS PROFILE {#drop-settings-profile-statement}
|
||||
|
||||
Deletes a quota.
|
||||
Deletes a settings profile.
|
||||
|
||||
Deleted quota is revoked from all the entities where it was assigned.
|
||||
Deleted settings profile is revoked from all the entities where it was assigned.
|
||||
|
||||
### Syntax {#drop-settings-profile-syntax}
|
||||
|
||||
@ -360,4 +360,4 @@ Lets you set the current database for the session.
|
||||
The current database is used for searching for tables if the database is not explicitly defined in the query with a dot before the table name.
|
||||
This query can’t be made when using the HTTP protocol, since there is no concept of a session.
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/query_language/misc/) <!--hide-->
|
||||
[Original article](https://clickhouse.tech/docs/en/query_language/misc/)
|
||||
|
@ -23,7 +23,7 @@ REVOKE [ON CLUSTER cluster_name] [ADMIN OPTION FOR] role [,...] FROM {user | rol
|
||||
|
||||
## Description {#revoke-description}
|
||||
|
||||
To revoke some privilege you can use a privilege of wider scope then you plan to revoke. For example, if a user has the `SELECT (x,y)` privilege, administrator can perform `REVOKE SELECT(x,y) ...`, or `REVOKE SELECT * ...`, or even `REVOKE ALL PRIVILEGES ...` query to revoke this privilege.
|
||||
To revoke some privilege you can use a privilege of a wider scope than you plan to revoke. For example, if a user has the `SELECT (x,y)` privilege, administrator can execute `REVOKE SELECT(x,y) ...`, or `REVOKE SELECT * ...`, or even `REVOKE ALL PRIVILEGES ...` query to revoke this privilege.
|
||||
|
||||
|
||||
### Partial Revokes {#partial-revokes-dscr}
|
||||
@ -32,14 +32,14 @@ You can revoke a part of a privilege. For example, if a user has the `SELECT *.*
|
||||
|
||||
## Examples {#revoke-example}
|
||||
|
||||
Grant the `john` user account with a privilege to select from all the databases excepting the `accounts` one:
|
||||
Grant the `john` user account with a privilege to select from all the databases, excepting the `accounts` one:
|
||||
|
||||
``` sql
|
||||
GRANT SELECT ON *.* TO john;
|
||||
REVOKE SELECT ON accounts.* FROM john;
|
||||
```
|
||||
|
||||
Grant the `mira` user account with a privilege to select from all the columns of the `accounts.staff` table excepting the `wage` one.
|
||||
Grant the `mira` user account with a privilege to select from all the columns of the `accounts.staff` table, excepting the `wage` one.
|
||||
|
||||
``` sql
|
||||
GRANT SELECT ON accounts.staff TO mira;
|
||||
|
@ -131,7 +131,7 @@ SHOW CREATE USER [name | CURRENT_USER]
|
||||
|
||||
## SHOW CREATE ROLE {#show-create-role-statement}
|
||||
|
||||
Shows parameters that were used at a [role creation](create.md#create-role-statement)
|
||||
Shows parameters that were used at a [role creation](create.md#create-role-statement).
|
||||
|
||||
### Syntax {#show-create-role-syntax}
|
||||
|
||||
@ -143,7 +143,7 @@ SHOW CREATE ROLE name
|
||||
|
||||
## SHOW CREATE ROW POLICY {#show-create-row-policy-statement}
|
||||
|
||||
Shows parameters that were used at a [row policy creation](create.md#create-row-policy-statement)
|
||||
Shows parameters that were used at a [row policy creation](create.md#create-row-policy-statement).
|
||||
|
||||
### Syntax {#show-create-row-policy-syntax}
|
||||
|
||||
@ -154,7 +154,7 @@ SHOW CREATE [ROW] POLICY name ON [database.]table
|
||||
|
||||
## SHOW CREATE QUOTA {#show-create-quota-statement}
|
||||
|
||||
Shows parameters that were used at a [quota creation](create.md#create-quota-statement)
|
||||
Shows parameters that were used at a [quota creation](create.md#create-quota-statement).
|
||||
|
||||
### Syntax {#show-create-row-policy-syntax}
|
||||
|
||||
@ -165,7 +165,7 @@ SHOW CREATE QUOTA [name | CURRENT]
|
||||
|
||||
## SHOW CREATE SETTINGS PROFILE {#show-create-settings-profile-statement}
|
||||
|
||||
Shows parameters that were used at a [settings profile creation](create.md#create-settings-profile-statement)
|
||||
Shows parameters that were used at a [settings profile creation](create.md#create-settings-profile-statement).
|
||||
|
||||
### Syntax {#show-create-row-policy-syntax}
|
||||
|
||||
|
@ -1,101 +1,143 @@
|
||||
# Права доступа {#prava-dostupa}
|
||||
# Управление доступом {#access-control}
|
||||
|
||||
Пользователи и права доступа настраиваются в конфиге пользователей. Обычно это `users.xml`.
|
||||
ClickHouse поддерживает управление доступом на основе подхода [RBAC](https://ru.wikipedia.org/wiki/Управление_доступом_на_основе_ролей).
|
||||
|
||||
Пользователи прописаны в секции `users`. Рассмотрим фрагмент файла `users.xml`:
|
||||
Объекты системы доступа в ClickHouse:
|
||||
|
||||
``` xml
|
||||
<!-- Пользователи и ACL. -->
|
||||
<users>
|
||||
<!-- Если имя пользователя не указано, используется пользователь default. -->
|
||||
<default>
|
||||
<!-- Password could be specified in plaintext or in SHA256 (in hex format).
|
||||
- [Аккаунт пользователя](#user-account-management)
|
||||
- [Роль](#role-management)
|
||||
- [Политика доступа к строкам](#row-policy-management)
|
||||
- [Профиль настроек](#settings-profiles-management)
|
||||
- [Квота](#quotas-management)
|
||||
|
||||
If you want to specify password in plaintext (not recommended), place it in 'password' element.
|
||||
Example: <password>qwerty</password>.
|
||||
Password could be empty.
|
||||
Вы можете настроить объекты системы доступа, используя:
|
||||
|
||||
If you want to specify SHA256, place it in 'password_sha256_hex' element.
|
||||
Example: <password_sha256_hex>65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5</password_sha256_hex>
|
||||
- SQL-ориентированный воркфлоу.
|
||||
|
||||
How to generate decent password:
|
||||
Execute: PASSWORD=$(base64 < /dev/urandom | head -c8); echo "$PASSWORD"; echo -n "$PASSWORD" | sha256sum | tr -d '-'
|
||||
In first line will be password and in second - corresponding SHA256.
|
||||
-->
|
||||
<password></password>
|
||||
Функциональность необходимо [включить](#enabling-access-control).
|
||||
|
||||
<!-- Список сетей, из которых разрешён доступ.
|
||||
Каждый элемент списка имеет одну из следующих форм:
|
||||
<ip> IP-адрес или маска подсети. Например, 198.51.100.0/24 или 2001:DB8::/32.
|
||||
<host> Имя хоста. Например: example01. Для проверки делается DNS-запрос, и все полученные адреса сравниваются с адресом клиента.
|
||||
<host_regexp> Регулярное выражение для имён хостов. Например, ^example\d\d-\d\d-\d\.host\.ru$
|
||||
Для проверки, для адреса клиента делается DNS PTR-запрос и к результату применяется регулярное выражение.
|
||||
Потом для результата PTR-запроса делается снова DNS-запрос, и все полученные адреса сравниваются с адресом клиента.
|
||||
Настоятельно рекомендуется, чтобы регулярное выражение заканчивалось на \.host\.ru$.
|
||||
- [Конфигурационные файлы](configuration-files.md) сервера: `users.xml` и `config.xml`.
|
||||
|
||||
Если вы устанавливаете ClickHouse самостоятельно, укажите здесь:
|
||||
<networks>
|
||||
<ip>::/0</ip>
|
||||
</networks>
|
||||
-->
|
||||
<networks incl="networks" />
|
||||
Рекомендуется использовать SQL-воркфлоу. Оба метода конфигурации работают одновременно, поэтому, если для управления доступом вы используете конфигурационные файлы, вы можете плавно перейти на SQL-воркфлоу.
|
||||
|
||||
<!-- Профиль настроек, использующийся для пользователя. -->
|
||||
<profile>default</profile>
|
||||
!!! note "Внимание"
|
||||
Нельзя одновременно использовать оба метода для управления одним и тем же объектом системы доступа.
|
||||
|
||||
<!-- Квота, использующаяся для пользователя. -->
|
||||
<quota>default</quota>
|
||||
</default>
|
||||
|
||||
<!-- Для запросов из пользовательского интерфейса Метрики через API для данных по отдельным счётчикам. -->
|
||||
<web>
|
||||
<password></password>
|
||||
<networks incl="networks" />
|
||||
<profile>web</profile>
|
||||
<quota>default</quota>
|
||||
<allow_databases>
|
||||
<database>test</database>
|
||||
</allow_databases>
|
||||
</web>
|
||||
```
|
||||
## Использование {#access-control-usage}
|
||||
|
||||
Здесь видно объявление двух пользователей - `default` и `web`. Пользователя `web` мы добавили самостоятельно.
|
||||
По умолчанию сервер ClickHouse предоставляет аккаунт пользователя `default`, для которого выключена функция SQL-ориентированного управления доступом, но у него есть все права и разрешения. Аккаунт `default` используется во всех случаях, когда имя пользователя не определено. Например, при входе с клиента или в распределенных запросах. При распределенной обработке запроса `default` используется, если в конфигурации сервера или кластера не указаны свойства [user и password](../engines/table-engines/special/distributed.md).
|
||||
|
||||
Пользователь `default` выбирается в случаях, когда имя пользователя не передаётся. Также пользователь `default` может использоваться при распределённой обработке запроса - если в конфигурации кластера для сервера не указаны `user` и `password`. (см. раздел о движке [Distributed](../engines/table-engines/special/distributed.md)).
|
||||
Если вы начали пользоваться ClickHouse недавно, попробуйте следующий сценарий:
|
||||
|
||||
Пользователь, который используется для обмена информацией между серверами, объединенными в кластер, не должен иметь существенных ограничений или квот - иначе распределённые запросы сломаются.
|
||||
1. [Включите](#enabling-access-control) SQL-ориентированное управление доступом для пользователя `default`.
|
||||
2. Войдите под пользователем `default` и создайте всех необходимых пользователей. Не забудьте создать аккаунт администратора (`GRANT ALL ON *.* WITH GRANT OPTION TO admin_user_account`).
|
||||
3. [Ограничьте разрешения](settings/permissions-for-queries.md#permissions_for_queries) для пользователя `default` и отключите для него SQL-ориентированное управление доступом.
|
||||
|
||||
Пароль указывается либо в открытом виде (не рекомендуется), либо в виде SHA-256. Хэш не содержит соль. В связи с этим, не следует рассматривать такие пароли, как защиту от потенциального злоумышленника. Скорее, они нужны для защиты от сотрудников.
|
||||
### Особенности реализации {#access-control-properties}
|
||||
|
||||
Указывается список сетей, из которых разрешён доступ. В этом примере, список сетей для обеих пользователей, загружается из отдельного файла (`/etc/metrika.xml`), содержащего подстановку `networks`. Вот его фрагмент:
|
||||
- Вы можете выдавать разрешения на базы данных или таблицы, даже если они не существуют.
|
||||
- При удалении таблицы все связанные с ней привилегии не отзываются. Если вы затем создадите новую таблицу с таким же именем, все привилегии останутся действительными. Чтобы отозвать привилегии, связанные с удаленной таблицей, необходимо выполнить, например, запрос `REVOKE ALL PRIVILEGES ON db.table FROM ALL`.
|
||||
- У привилегий нет настроек времени жизни.
|
||||
|
||||
``` xml
|
||||
<yandex>
|
||||
...
|
||||
<networks>
|
||||
<ip>::/64</ip>
|
||||
<ip>203.0.113.0/24</ip>
|
||||
<ip>2001:DB8::/32</ip>
|
||||
...
|
||||
</networks>
|
||||
</yandex>
|
||||
```
|
||||
## Аккаунт пользователя {#user-account-management}
|
||||
|
||||
Можно было бы указать этот список сетей непосредственно в `users.xml`, или в файле в директории `users.d` (подробнее смотрите раздел «[Конфигурационные файлы](configuration-files.md#configuration_files)»).
|
||||
Аккаунт пользователя — это объект системы доступа, позволяющий авторизовать кого-либо в ClickHouse. Аккаунт содержит:
|
||||
|
||||
В конфиге приведён комментарий, указывающий, как можно открыть доступ отовсюду.
|
||||
- Идентификационную информацию.
|
||||
- [Привилегии](../sql-reference/statements/grant.md#grant-privileges), определяющие область действия запросов, которые могут быть выполнены пользователем.
|
||||
- Хосты, которые могут подключаться к серверу ClickHouse.
|
||||
- Назначенные роли и роли по умолчанию.
|
||||
- Настройки и их ограничения, которые применяются по умолчанию при входе пользователя.
|
||||
- Присвоенные профили настроек.
|
||||
|
||||
Для продакшен использования, указывайте только элементы вида `ip` (IP-адреса и их маски), так как использование `host` и `host_regexp` может вызывать лишние задержки.
|
||||
Привилегии присваиваются аккаунту пользователя с помощью запроса [GRANT](../sql-reference/statements/grant.md) или через назначение [ролей](#role-management). Отозвать привилегию можно с помощью запроса [REVOKE](../sql-reference/statements/revoke.md). Чтобы вывести список присвоенных привилегий, используется выражение [SHOW GRANTS](../sql-reference/statements/show.md#show-grants-statement).
|
||||
|
||||
Далее указывается используемый профиль настроек пользователя (смотрите раздел «[Профили настроек](settings/settings-profiles.md)»). Вы можете указать профиль по умолчанию - `default`. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек `readonly=1`, что обеспечивает доступ только на чтение.
|
||||
Затем указывается используемая квота (смотрите раздел «[Квоты](quotas.md#quotas)»). Вы можете указать квоту по умолчанию — `default`. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно. Одна и та же квота может быть указана для разных пользователей, в этом случае подсчёт использования ресурсов делается для каждого пользователя по отдельности.
|
||||
Запросы управления:
|
||||
|
||||
Также, в необязательном разделе `<allow_databases>` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных `default`, в этом случае пользователь получит доступ к базе данных по умолчанию.
|
||||
- [CREATE USER](../sql-reference/statements/create.md#create-user-statement)
|
||||
- [ALTER USER](../sql-reference/statements/alter.md#alter-user-statement)
|
||||
- [DROP USER](../sql-reference/statements/misc.md#drop-user-statement)
|
||||
- [SHOW CREATE USER](../sql-reference/statements/show.md#show-create-user-statement)
|
||||
|
||||
Доступ к БД `system` всегда считается разрешённым (так как эта БД используется для выполнения запросов).
|
||||
### Применение настроек {#access-control-settings-applying}
|
||||
|
||||
Пользователь может получить список всех БД и таблиц в них с помощью запросов `SHOW` или системных таблиц, даже если у него нет доступа к отдельным БД.
|
||||
Настройки могут быть заданы разными способами: для аккаунта пользователя, для назначенных ему ролей или в профилях настроек. При входе пользователя, если настройка задана для разных объектов системы доступа, значение настройки и ее ограничения применяются в следующем порядке (от высшего приоритета к низшему):
|
||||
|
||||
1. Настройки аккаунта.
|
||||
2. Настройки ролей по умолчанию для аккаунта. Если настройка задана для нескольких ролей, порядок применения не определен.
|
||||
3. Настройки из профилей настроек, присвоенных пользователю или его ролям по умолчанию. Если настройка задана в нескольких профилях, порядок применения не определен.
|
||||
4. Настройки, которые по умолчанию применяются ко всему серверу, или настройки из [профиля по умолчанию](server-configuration-parameters/settings.md#default-profile).
|
||||
|
||||
|
||||
## Роль {#role-management}
|
||||
|
||||
Роль — это контейнер объектов системы доступа, которые можно присвоить аккаунту пользователя.
|
||||
|
||||
Роль содержит:
|
||||
|
||||
- [Привилегии](../sql-reference/statements/grant.md#grant-privileges)
|
||||
- Настройки и ограничения
|
||||
- Список назначенных ролей
|
||||
|
||||
Запросы управления:
|
||||
|
||||
- [CREATE ROLE](../sql-reference/statements/create.md#create-role-statement)
|
||||
- [ALTER ROLE](../sql-reference/statements/alter.md#alter-role-statement)
|
||||
- [DROP ROLE](../sql-reference/statements/misc.md#drop-role-statement)
|
||||
- [SET ROLE](../sql-reference/statements/misc.md#set-role-statement)
|
||||
- [SET DEFAULT ROLE](../sql-reference/statements/misc.md#set-default-role-statement)
|
||||
- [SHOW CREATE ROLE](../sql-reference/statements/show.md#show-create-role-statement)
|
||||
|
||||
Привилегии можно присвоить роли с помощью запроса [GRANT](../sql-reference/statements/grant.md). Для отзыва привилегий у роли ClickHouse предоставляет запрос [REVOKE](../sql-reference/statements/revoke.md).
|
||||
|
||||
## Политика доступа к строкам {#row-policy-management}
|
||||
|
||||
Политика доступа к строкам — это фильтр, определяющий, какие строки доступны пользователю или роли. Политика содержит фильтры для конкретной таблицы, а также список ролей и/или пользователей, которые должны использовать данную политику.
|
||||
|
||||
Запросы управления:
|
||||
|
||||
- [CREATE ROW POLICY](../sql-reference/statements/create.md#create-row-policy-statement)
|
||||
- [ALTER ROW POLICY](../sql-reference/statements/alter.md#alter-row-policy-statement)
|
||||
- [DROP ROW POLICY](../sql-reference/statements/misc.md#drop-row-policy-statement)
|
||||
- [SHOW CREATE ROW POLICY](../sql-reference/statements/show.md#show-create-row-policy-statement)
|
||||
|
||||
|
||||
## Профиль настроек {#settings-profiles-management}
|
||||
|
||||
Профиль настроек — это набор [настроек](settings/index.md). Профиль настроек содержит настройки и ограничения, а также список ролей и/или пользователей, по отношению к которым применяется данный профиль.
|
||||
|
||||
Запросы управления:
|
||||
|
||||
- [CREATE SETTINGS PROFILE](../sql-reference/statements/create.md#create-settings-profile-statement)
|
||||
- [ALTER SETTINGS PROFILE](../sql-reference/statements/alter.md#alter-settings-profile-statement)
|
||||
- [DROP SETTINGS PROFILE](../sql-reference/statements/misc.md#drop-settings-profile-statement)
|
||||
- [SHOW CREATE SETTINGS PROFILE](../sql-reference/statements/show.md#show-create-settings-profile-statement)
|
||||
|
||||
|
||||
## Квота {#quotas-management}
|
||||
|
||||
Квота ограничивает использование ресурсов. См. [Квоты](quotas.md).
|
||||
|
||||
Квота содержит набор ограничений определенной длительности, а также список ролей и/или пользователей, на которых распространяется данная квота.
|
||||
|
||||
Запросы управления:
|
||||
|
||||
- [CREATE QUOTA](../sql-reference/statements/create.md#create-quota-statement)
|
||||
- [ALTER QUOTA](../sql-reference/statements/alter.md#alter-quota-statement)
|
||||
- [DROP QUOTA](../sql-reference/statements/misc.md#drop-quota-statement)
|
||||
- [SHOW CREATE QUOTA](../sql-reference/statements/show.md#show-create-quota-statement)
|
||||
|
||||
|
||||
## Включение SQL-ориентированного управления доступом {#enabling-access-control}
|
||||
|
||||
- Настройте каталог для хранения конфигураций.
|
||||
|
||||
ClickHouse хранит конфигурации объектов системы доступа в каталоге, установленном в конфигурационном параметре сервера [access_control_path](server-configuration-parameters/settings.md#access_control_path).
|
||||
|
||||
- Включите SQL-ориентированное управление доступом как минимум для одного аккаунта.
|
||||
|
||||
По умолчанию управление доступом на основе SQL выключено для всех пользователей. Вам необходимо настроить хотя бы одного пользователя в файле конфигурации `users.xml` и присвоить значение 1 параметру [access_management](settings/settings-users.md#access_management-user-setting).
|
||||
|
||||
Доступ к БД не связан с настройкой [readonly](settings/permissions-for-queries.md#settings_readonly). Невозможно дать полный доступ к одной БД и `readonly` к другой.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/access_rights/) <!--hide-->
|
||||
|
@ -832,4 +832,14 @@ ClickHouse использует ZooKeeper для хранения метадан
|
||||
|
||||
**Значение по умолчанию**: 15.
|
||||
|
||||
## access_control_path {#access_control_path}
|
||||
|
||||
Путь к каталогу, где сервер ClickHouse хранит конфигурации пользователей и ролей, созданные командами SQL.
|
||||
|
||||
Значение по умолчанию: `/var/lib/clickhouse/access/`.
|
||||
|
||||
**Смотрите также**
|
||||
|
||||
- [Управление доступом](../access-rights.md#access-control)
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/server_configuration_parameters/settings/) <!--hide-->
|
||||
|
@ -1,6 +1,15 @@
|
||||
# Профили настроек {#profili-nastroek}
|
||||
# Профили настроек {#settings-profiles}
|
||||
|
||||
Профиль настроек — это набор настроек, сгруппированных под одним именем.
|
||||
|
||||
!!! note "Информация"
|
||||
Для управления профилями настроек рекомендуется использовать [SQL-ориентированный воркфлоу](../access-rights.md#access-control), который также поддерживается в ClickHouse.
|
||||
|
||||
|
||||
Название профиля может быть любым. Вы можете указать один и тот же профиль для разных пользователей. Самое важное, что можно прописать в профиле — `readonly=1`, это обеспечит доступ только на чтение.
|
||||
|
||||
Профили настроек поддерживают наследование. Это реализуется указанием одной или нескольких настроек `profile` перед остальными настройками, перечисленными в профиле. Если одна настройка указана в нескольких профилях, используется последнее из значений.
|
||||
|
||||
Профили настроек - это множество настроек, сгруппированных под одним именем. Для каждого пользователя ClickHouse указывается некоторый профиль.
|
||||
Все настройки профиля можно применить, установив настройку `profile`.
|
||||
|
||||
Пример:
|
||||
@ -57,8 +66,10 @@ SET profile = 'web'
|
||||
</profiles>
|
||||
```
|
||||
|
||||
В примере задано два профиля: `default` и `web`. Профиль `default` имеет специальное значение - он всегда обязан присутствовать и применяется при запуске сервера. То есть, профиль `default` содержит настройки по умолчанию. Профиль `web` - обычный профиль, который может быть установлен с помощью запроса `SET` или с помощью параметра URL при запросе по HTTP.
|
||||
В примере задано два профиля: `default` и `web`.
|
||||
|
||||
Профили настроек могут наследоваться от друг-друга - это реализуется указанием одной или нескольких настроек `profile` перед остальными настройками, перечисленными в профиле. Если одна настройка указана в нескольких профилях, используется последнее из значений.
|
||||
Профиль `default` имеет специальное значение — он обязателен и применяется при запуске сервера. Профиль `default` содержит настройки по умолчанию.
|
||||
|
||||
Профиль `web` — обычный профиль, который может быть установлен с помощью запроса `SET` или параметра URL при запросе по HTTP.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/settings/settings_profiles/) <!--hide-->
|
||||
|
@ -2,6 +2,9 @@
|
||||
|
||||
Раздел `users` конфигурационного файла `user.xml` содержит настройки для пользователей.
|
||||
|
||||
!!! note "Информация"
|
||||
Для управления пользователями рекомендуется использовать [SQL-ориентированный воркфлоу](../access-rights.md#access-control), который также поддерживается в ClickHouse.
|
||||
|
||||
Структура раздела `users`:
|
||||
|
||||
``` xml
|
||||
@ -12,6 +15,8 @@
|
||||
<!-- Or -->
|
||||
<password_sha256_hex></password_sha256_hex>
|
||||
|
||||
<access_management>0|1</access_management>
|
||||
|
||||
<networks incl="networks" replace="replace">
|
||||
</networks>
|
||||
|
||||
@ -67,6 +72,17 @@
|
||||
|
||||
Первая строка результата — пароль. Вторая строка — соответствующий ему двойной хэш SHA1.
|
||||
|
||||
### access_management {#access_management-user-setting}
|
||||
|
||||
Включает или выключает SQL-ориентированное [управление доступом](../access-rights.md#access-control) для пользователя.
|
||||
|
||||
Возможные значения:
|
||||
|
||||
- 0 — Выключено.
|
||||
- 1 — Включено.
|
||||
|
||||
Значение по умолчанию: 0.
|
||||
|
||||
### user\_name/networks {#user-namenetworks}
|
||||
|
||||
Список сетей, из которых пользователь может подключиться к серверу ClickHouse.
|
||||
|
@ -498,8 +498,112 @@ ALTER TABLE [db.]table MATERIALIZE INDEX name IN PARTITION partition_name
|
||||
|
||||
Мутации линейно упорядочены между собой и накладываются на каждый кусок в порядке добавления. Мутации также упорядочены со вставками - гарантируется, что данные, вставленные в таблицу до начала выполнения запроса мутации, будут изменены, а данные, вставленные после окончания запроса мутации, изменены не будут. При этом мутации никак не блокируют вставки.
|
||||
|
||||
Запрос завершается немедленно после добавления информации о мутации (для реплицированных таблиц - в ZooKeeper, для нереплицированных - на файловую систему). Сама мутация выполняется асинхронно, используя настройки системного профиля. Следить за ходом её выполнения можно по таблице [`system.mutations`](../../operations/system-tables.md#system_tables-mutations). Добавленные мутации будут выполняться до конца даже в случае перезапуска серверов ClickHouse. Откатить мутацию после её добавления нельзя, но если мутация по какой-то причине не может выполниться до конца, её можно остановить с помощью запроса [`KILL MUTATION`](misc.md#kill-mutation).
|
||||
Запрос завершается немедленно после добавления информации о мутации (для реплицированных таблиц - в ZooKeeper, для нереплицированных - на файловую систему). Сама мутация выполняется асинхронно, используя настройки системного профиля. Следить за ходом её выполнения можно по таблице [`system.mutations`](../../operations/system-tables.md#system_tables-mutations). Добавленные мутации будут выполняться до конца даже в случае перезапуска серверов ClickHouse. Откатить мутацию после её добавления нельзя, но если мутация по какой-то причине не может выполниться до конца, её можно остановить с помощью запроса [`KILL MUTATION`](misc.md#kill-mutation-statement).
|
||||
|
||||
Записи о последних выполненных мутациях удаляются не сразу (количество сохраняемых мутаций определяется параметром движка таблиц `finished_mutations_to_keep`). Более старые записи удаляются.
|
||||
|
||||
## ALTER USER {#alter-user-statement}
|
||||
|
||||
Изменяет аккаунт пользователя ClickHouse.
|
||||
|
||||
### Синтаксис {#alter-user-syntax}
|
||||
|
||||
``` sql
|
||||
ALTER USER [IF EXISTS] name [ON CLUSTER cluster_name]
|
||||
[RENAME TO new_name]
|
||||
[IDENTIFIED [WITH {PLAINTEXT_PASSWORD|SHA256_PASSWORD|DOUBLE_SHA1_PASSWORD}] BY {'password'|'hash'}]
|
||||
[[ADD|DROP] HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
|
||||
[DEFAULT ROLE role [,...] | ALL | ALL EXCEPT role [,...] ]
|
||||
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE] | PROFILE 'profile_name'] [,...]
|
||||
```
|
||||
|
||||
### Описание {#alter-user-dscr}
|
||||
|
||||
Для выполнения `ALTER USER` необходима привилегия [ALTER USER](grant.md#grant-access-management).
|
||||
|
||||
### Примеры {#alter-user-examples}
|
||||
|
||||
Установить ролями по умолчанию роли, назначенные пользователю:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE role1, role2
|
||||
```
|
||||
|
||||
Если роли не были назначены пользователю, ClickHouse выбрасывает исключение.
|
||||
|
||||
Установить ролями по умолчанию все роли, назначенные пользователю:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE ALL
|
||||
```
|
||||
|
||||
Если роль будет впоследствии назначена пользователю, она автоматически станет ролью по умолчанию.
|
||||
|
||||
Установить ролями по умолчанию все назначенные пользователю роли кроме `role1` и `role2`:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2
|
||||
```
|
||||
|
||||
|
||||
## ALTER ROLE {#alter-role-statement}
|
||||
|
||||
Изменяет роль.
|
||||
|
||||
### Синтаксис {#alter-role-syntax}
|
||||
|
||||
``` sql
|
||||
ALTER ROLE [IF EXISTS] name [ON CLUSTER cluster_name]
|
||||
[RENAME TO new_name]
|
||||
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE] | PROFILE 'profile_name'] [,...]
|
||||
```
|
||||
|
||||
|
||||
## ALTER ROW POLICY {#alter-row-policy-statement}
|
||||
|
||||
Изменяет политику доступа к строкам.
|
||||
|
||||
### Синтаксис {#alter-row-policy-syntax}
|
||||
|
||||
``` sql
|
||||
ALTER [ROW] POLICY [IF EXISTS] name [ON CLUSTER cluster_name] ON [database.]table
|
||||
[RENAME TO new_name]
|
||||
[AS {PERMISSIVE | RESTRICTIVE}]
|
||||
[FOR SELECT]
|
||||
[USING {condition | NONE}][,...]
|
||||
[TO {role [,...] | ALL | ALL EXCEPT role [,...]}]
|
||||
```
|
||||
|
||||
|
||||
## ALTER QUOTA {#alter-quota-statement}
|
||||
|
||||
Изменяет квоту.
|
||||
|
||||
### Синтаксис {#alter-quota-syntax}
|
||||
|
||||
``` sql
|
||||
ALTER QUOTA [IF EXISTS] name [ON CLUSTER cluster_name]
|
||||
[RENAME TO new_name]
|
||||
[KEYED BY {'none' | 'user name' | 'ip address' | 'client key' | 'client key or user name' | 'client key or ip address'}]
|
||||
[FOR [RANDOMIZED] INTERVAL number {SECOND | MINUTE | HOUR | DAY}
|
||||
{MAX { {QUERIES | ERRORS | RESULT ROWS | RESULT BYTES | READ ROWS | READ BYTES | EXECUTION TIME} = number } [,...] |
|
||||
NO LIMITS | TRACKING ONLY} [,...]]
|
||||
[TO {role [,...] | ALL | ALL EXCEPT role [,...]}]
|
||||
```
|
||||
|
||||
|
||||
## ALTER SETTINGS PROFILE {#alter-settings-profile-statement}
|
||||
|
||||
Изменяет профили настроек.
|
||||
|
||||
### Синтаксис {#alter-settings-profile-syntax}
|
||||
|
||||
``` sql
|
||||
ALTER SETTINGS PROFILE [IF EXISTS] name [ON CLUSTER cluster_name]
|
||||
[RENAME TO new_name]
|
||||
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE] | INHERIT 'profile_name'] [,...]
|
||||
```
|
||||
|
||||
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/query_language/alter/) <!--hide-->
|
||||
|
@ -302,4 +302,206 @@ LIFETIME([MIN val1] MAX val2)
|
||||
|
||||
Смотрите [Внешние словари](../../sql-reference/statements/create.md).
|
||||
|
||||
## CREATE USER {#create-user-statement}
|
||||
|
||||
Создает [аккаунт пользователя](../../operations/access-rights.md#user-account-management).
|
||||
|
||||
### Синтаксис {#create-user-syntax}
|
||||
|
||||
```sql
|
||||
CREATE USER [IF NOT EXISTS | OR REPLACE] name [ON CLUSTER cluster_name]
|
||||
[IDENTIFIED [WITH {NO_PASSWORD|PLAINTEXT_PASSWORD|SHA256_PASSWORD|SHA256_HASH|DOUBLE_SHA1_PASSWORD|DOUBLE_SHA1_HASH}] BY {'password'|'hash'}]
|
||||
[HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
|
||||
[DEFAULT ROLE role [,...]]
|
||||
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE] | PROFILE 'profile_name'] [,...]
|
||||
```
|
||||
|
||||
#### Идентификация
|
||||
|
||||
Существует несколько способов идентификации пользователя:
|
||||
|
||||
- `IDENTIFIED WITH no_password`
|
||||
- `IDENTIFIED WITH plaintext_password BY 'qwerty'`
|
||||
- `IDENTIFIED WITH sha256_password BY 'qwerty'` or `IDENTIFIED BY 'password'`
|
||||
- `IDENTIFIED WITH sha256_hash BY 'hash'`
|
||||
- `IDENTIFIED WITH double_sha1_password BY 'qwerty'`
|
||||
- `IDENTIFIED WITH double_sha1_hash BY 'hash'`
|
||||
|
||||
#### Пользовательский хост
|
||||
|
||||
Пользовательский хост — это хост, с которого можно установить соединение с сервером ClickHouse. Хост задается в секции `HOST` следующими способами:
|
||||
|
||||
- `HOST IP 'ip_address_or_subnetwork'` — Пользователь может подключиться к серверу ClickHouse только с указанного IP-адреса или [подсети](https://ru.wikipedia.org/wiki/Подсеть). Примеры: `HOST IP '192.168.0.0/16'`, `HOST IP '2001:DB8::/32'`. При использовании в эксплуатации указывайте только элементы `HOST IP` (IP-адреса и маски подсети), так как использование `host` и `host_regexp` может привести к дополнительной задержке.
|
||||
- `HOST ANY` — Пользователь может подключиться с любого хоста. Используется по умолчанию.
|
||||
- `HOST LOCAL` — Пользователь может подключиться только локально.
|
||||
- `HOST NAME 'fqdn'` — Хост задается через FQDN. Например, `HOST NAME 'mysite.com'`.
|
||||
- `HOST NAME REGEXP 'regexp'` — Позволяет использовать регулярные выражения [pcre](http://www.pcre.org/), чтобы задать хосты. Например, `HOST NAME REGEXP '.*\.mysite\.com'`.
|
||||
- `HOST LIKE 'template'` — Позволяет использовать оператор [LIKE](../functions/string-search-functions.md#function-like) для фильтрации хостов. Например, `HOST LIKE '%'` эквивалентен `HOST ANY`; `HOST LIKE '%.mysite.com'` разрешает подключение со всех хостов в домене `mysite.com`.
|
||||
|
||||
Также, чтобы задать хост, вы можете использовать `@` вместе с именем пользователя. Примеры:
|
||||
|
||||
- `CREATE USER mira@'127.0.0.1'` — Эквивалентно `HOST IP`.
|
||||
- `CREATE USER mira@'localhost'` — Эквивалентно `HOST LOCAL`.
|
||||
- `CREATE USER mira@'192.168.%.%'` — Эквивалентно `HOST LIKE`.
|
||||
|
||||
!!! info "Внимание"
|
||||
ClickHouse трактует конструкцию `user_name@'address'` как имя пользователя целиком. То есть технически вы можете создать несколько пользователей с одинаковыми `user_name`, но разными частями конструкции после `@`, но лучше так не делать.
|
||||
|
||||
|
||||
### Примеры {#create-user-examples}
|
||||
|
||||
|
||||
Создать аккаунт `mira`, защищенный паролем `qwerty`:
|
||||
|
||||
```sql
|
||||
CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty'
|
||||
```
|
||||
|
||||
Пользователь `mira` должен запустить клиентское приложение на хосте, где запущен ClickHouse.
|
||||
|
||||
Создать аккаунт `john`, назначить на него роли, сделать данные роли ролями по умолчанию:
|
||||
|
||||
``` sql
|
||||
CREATE USER john DEFAULT ROLE role1, role2
|
||||
```
|
||||
|
||||
Создать аккаунт `john` и установить ролями по умолчанию все его будущие роли:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE ALL
|
||||
```
|
||||
|
||||
Когда роль будет назначена аккаунту `john`, она автоматически станет ролью по умолчанию.
|
||||
|
||||
Создать аккаунт `john` и установить ролями по умолчанию все его будущие роли, кроме `role1` и `role2`:
|
||||
|
||||
``` sql
|
||||
ALTER USER john DEFAULT ROLE ALL EXCEPT role1, role2
|
||||
```
|
||||
|
||||
|
||||
## CREATE ROLE {#create-role-statement}
|
||||
|
||||
Создает [роль](../../operations/access-rights.md#role-management).
|
||||
|
||||
### Синтаксис {#create-role-syntax}
|
||||
|
||||
```sql
|
||||
CREATE ROLE [IF NOT EXISTS | OR REPLACE] name
|
||||
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE] | PROFILE 'profile_name'] [,...]
|
||||
```
|
||||
|
||||
### Описание {#create-role-description}
|
||||
|
||||
Роль — это набор [привилегий](grant.md#grant-privileges). Пользователь, которому назначена роль, получает все привилегии этой роли.
|
||||
|
||||
Одному пользователю можно назначить несколько ролей. Пользователи могут применять назначенные роли в произвольных комбинациях с помощью выражения [SET ROLE](misc.md#set-role-statement). Конечный объем привилегий — это комбинация всех привилегий всех примененных ролей. Если у пользователя имеются привилегии, присвоенные его аккаунту напрямую, они также прибавляются к привилегиям, присвоенным через роли.
|
||||
|
||||
Роли по умолчанию применяются при входе пользователя в систему. Установить роли по умолчанию можно с помощью выражений [SET DEFAULT ROLE](misc.md#set-default-role-statement) или [ALTER USER](alter.md#alter-user-statement).
|
||||
|
||||
Для отзыва роли используется выражение [REVOKE](revoke.md).
|
||||
|
||||
Для удаления роли используется выражение [DROP ROLE](misc.md#drop-role-statement). Удаленная роль автоматически отзывается у всех пользователей, которым была назначена.
|
||||
|
||||
### Примеры {#create-role-examples}
|
||||
|
||||
```sql
|
||||
CREATE ROLE accountant;
|
||||
GRANT SELECT ON db.* TO accountant;
|
||||
```
|
||||
|
||||
Такая последовательность запросов создаст роль `accountant`, у которой есть привилегия на чтение из базы данных `accounting`.
|
||||
|
||||
Назначить роль `accountant` аккаунту `mira`:
|
||||
|
||||
```sql
|
||||
GRANT accountant TO mira;
|
||||
```
|
||||
|
||||
После назначения роли пользователь может ее применить и выполнять разрешенные ей запросы. Например:
|
||||
|
||||
```sql
|
||||
SET ROLE accountant;
|
||||
SELECT * FROM db.*;
|
||||
```
|
||||
|
||||
## CREATE ROW POLICY {#create-row-policy-statement}
|
||||
|
||||
Создает [фильтр для строк](../../operations/access-rights.md#row-policy-management), которые пользователь может прочесть из таблицы.
|
||||
|
||||
### Синтаксис {#create-row-policy-syntax}
|
||||
|
||||
``` sql
|
||||
CREATE [ROW] POLICY [IF NOT EXISTS | OR REPLACE] policy_name [ON CLUSTER cluster_name] ON [db.]table
|
||||
[AS {PERMISSIVE | RESTRICTIVE}]
|
||||
[FOR SELECT]
|
||||
[USING condition]
|
||||
[TO {role [,...] | ALL | ALL EXCEPT role [,...]}]
|
||||
```
|
||||
|
||||
#### Секция AS {#create-row-policy-as}
|
||||
|
||||
С помощью данной секции можно создать политику разрешения или ограничения.
|
||||
|
||||
Политика разрешения предоставляет доступ к строкам. Разрешительные политики, которые применяются к одной таблице, объединяются с помощью логического оператора `OR`. Политики являются разрешительными по умолчанию.
|
||||
|
||||
Политика ограничения запрещает доступ к строкам. Ограничительные политики, которые применяются к одной таблице, объединяются логическим оператором `AND`.
|
||||
|
||||
Ограничительные политики применяются к строкам, прошедшим фильтр разрешительной политики. Если вы не зададите разрешительные политики, пользователь не сможет обращаться ни к каким строкам из таблицы.
|
||||
|
||||
#### Секция TO {#create-row-policy-to}
|
||||
|
||||
В секции `TO` вы можете перечислить как роли, так и пользователей. Например, `CREATE ROW POLICY ... TO accountant, john@localhost`.
|
||||
|
||||
Ключевым словом `ALL` обозначаются все пользователи, включая текущего. Ключевые слова `ALL EXCEPT` позволяют исключить пользователей из списка всех пользователей. Например, `CREATE ROW POLICY ... TO ALL EXCEPT accountant, john@localhost`
|
||||
|
||||
### Примеры
|
||||
|
||||
- `CREATE ROW POLICY filter ON mydb.mytable FOR SELECT USING a<1000 TO accountant, john@localhost`
|
||||
- `CREATE ROW POLICY filter ON mydb.mytable FOR SELECT USING a<1000 TO ALL EXCEPT mira`
|
||||
|
||||
|
||||
## CREATE QUOTA {#create-quota-statement}
|
||||
|
||||
Создает [квоту](../../operations/access-rights.md#quotas-management), которая может быть присвоена пользователю или роли.
|
||||
|
||||
### Синтаксис {#create-quota-syntax}
|
||||
|
||||
``` sql
|
||||
CREATE QUOTA [IF NOT EXISTS | OR REPLACE] name [ON CLUSTER cluster_name]
|
||||
[KEYED BY {'none' | 'user name' | 'ip address' | 'client key' | 'client key or user name' | 'client key or ip address'}]
|
||||
[FOR [RANDOMIZED] INTERVAL number {SECOND | MINUTE | HOUR | DAY}
|
||||
{MAX { {QUERIES | ERRORS | RESULT ROWS | RESULT BYTES | READ ROWS | READ BYTES | EXECUTION TIME} = number } [,...] |
|
||||
NO LIMITS | TRACKING ONLY} [,...]]
|
||||
[TO {role [,...] | ALL | ALL EXCEPT role [,...]}]
|
||||
```
|
||||
|
||||
### Пример {#create-quota-example}
|
||||
|
||||
Ограничить максимальное количество запросов для текущего пользователя до 123 запросов каждые 15 месяцев:
|
||||
|
||||
``` sql
|
||||
CREATE QUOTA qA FOR INTERVAL 15 MONTH MAX QUERIES 123 TO CURRENT_USER
|
||||
```
|
||||
|
||||
|
||||
## CREATE SETTINGS PROFILE {#create-settings-profile-statement}
|
||||
|
||||
Создает [профиль настроек](../../operations/access-rights.md#settings-profiles-management), который может быть присвоен пользователю или роли.
|
||||
|
||||
### Синтаксис {#create-settings-profile-syntax}
|
||||
|
||||
``` sql
|
||||
CREATE SETTINGS PROFILE [IF NOT EXISTS | OR REPLACE] name [ON CLUSTER cluster_name]
|
||||
[SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE] | INHERIT 'profile_name'] [,...]
|
||||
```
|
||||
|
||||
### Пример {#create-settings-profile-syntax}
|
||||
|
||||
Создать профиль настроек `max_memory_usage_profile`, который содержит значение и ограничения для настройки `max_memory_usage`. Присвоить профиль пользователю `robin`:
|
||||
|
||||
``` sql
|
||||
CREATE SETTINGS PROFILE max_memory_usage_profile SETTINGS max_memory_usage = 100000001 MIN 90000000 MAX 110000000 TO robin
|
||||
```
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/query_language/create/) <!--hide-->
|
||||
|
@ -1 +0,0 @@
|
||||
../../../en/sql-reference/statements/grant.md
|
479
docs/ru/sql-reference/statements/grant.md
Normal file
479
docs/ru/sql-reference/statements/grant.md
Normal file
@ -0,0 +1,479 @@
|
||||
# GRANT
|
||||
|
||||
- Присваивает [привилегии](#grant-privileges) пользователям или ролям ClickHouse.
|
||||
- Назначает роли пользователям или другим ролям.
|
||||
|
||||
Отозвать привилегию можно с помощью выражения [REVOKE](revoke.md). Чтобы вывести список присвоенных привилегий, воспользуйтесь выражением [SHOW GRANTS](show.md#show-grants-statement).
|
||||
|
||||
## Синтаксис присвоения привилегий {#grant-privigele-syntax}
|
||||
|
||||
```sql
|
||||
GRANT [ON CLUSTER cluster_name] privilege[(column_name [,...])] [,...] ON {db.table|db.*|*.*|table|*} TO {user | role | CURRENT_USER} [,...] [WITH GRANT OPTION]
|
||||
```
|
||||
|
||||
- `privilege` — Тип привилегии
|
||||
- `role` — Роль пользователя ClickHouse.
|
||||
- `user` — Пользователь ClickHouse.
|
||||
|
||||
`WITH GRANT OPTION` разрешает пользователю или роли выполнять запрос `GRANT`. Пользователь может выдавать только те привилегии, которые есть у него, той же или меньшей области действий.
|
||||
|
||||
|
||||
## Синтаксис назначения ролей {#assign-role-syntax}
|
||||
|
||||
```sql
|
||||
GRANT [ON CLUSTER cluster_name] role [,...] TO {user | another_role | CURRENT_USER} [,...] [WITH ADMIN OPTION]
|
||||
```
|
||||
|
||||
- `role` — Роль пользователя ClickHouse.
|
||||
- `user` — Пользователь ClickHouse.
|
||||
|
||||
`WITH ADMIN OPTION` присваивает привилегию [ADMIN OPTION](#admin-option-privilege) пользователю или роли.
|
||||
|
||||
## Использование {#grant-usage}
|
||||
|
||||
Для использования `GRANT` пользователь должен иметь привилегию `GRANT OPTION`. Пользователь может выдавать привилегии только внутри области действий назначенных ему самому привилегий.
|
||||
|
||||
Например, администратор выдал привилегию пользователю `john`:
|
||||
|
||||
```sql
|
||||
GRANT SELECT(x,y) ON db.table TO john WITH GRANT OPTION
|
||||
```
|
||||
|
||||
Это означает, что пользователю `john` разрешено выполнять:
|
||||
|
||||
- `SELECT x,y FROM db.table`.
|
||||
- `SELECT x FROM db.table`.
|
||||
- `SELECT y FROM db.table`.
|
||||
|
||||
`john` не может выполнить `SELECT z FROM db.table` или `SELECT * FROM db.table`. После обработки данных запросов ClickHouse ничего не вернет — даже `x` или `y`. Единственное исключение — если таблица содержит только столбцы `x` и `y`. В таком случае ClickHouse вернет все данные.
|
||||
|
||||
Также у `john` есть привилегия `GRANT OPTION`. `john` может выдать другим пользователям привилегии той же или меньшей области действий из тех, которые есть у него.
|
||||
|
||||
При присвоении привилегий допускается использовать астериск (`*`) вместо имени таблицы или базы данных. Например, запрос `GRANT SELECT ON db.* TO john` позволит пользователю `john` выполнять `SELECT` над всеми таблицам в базе данных `db`. Также вы можете опускать имя базы данных. В таком случае привилегии позволят совершать операции над текущей базой данных. Например, запрос `GRANT SELECT ON * TO john` выдаст привилегию на выполнение `SELECT` над всеми таблицами в текущей базе данных; `GRANT SELECT ON mytable TO john` — только над таблицей `mytable` в текущей базе данных.
|
||||
|
||||
Доступ к базе данных `system` разрешен всегда (данная база данных используется при обработке запросов).
|
||||
|
||||
Вы можете присвоить несколько привилегий нескольким пользователям в одном запросе. Запрос `GRANT SELECT, INSERT ON *.* TO john, robin` позволит пользователям `john` и `robin` выполнять `INSERT` и `SELECT` над всеми таблицами всех баз данных на сервере.
|
||||
|
||||
|
||||
## Привилегии {#grant-privileges}
|
||||
|
||||
Привилегия — это разрешение на выполнение определенного типа запросов.
|
||||
|
||||
Привилегии имеют иерархическую структуру. Набор разрешенных запросов зависит от области действия привилегии.
|
||||
|
||||
Иерархия привилегий:
|
||||
|
||||
- [SELECT](#grant-select)
|
||||
- [INSERT](#grant-insert)
|
||||
- [ALTER](#grant-alter)
|
||||
- `ALTER TABLE`
|
||||
- `ALTER UPDATE`
|
||||
- `ALTER DELETE`
|
||||
- `ALTER COLUMN`
|
||||
- `ALTER ADD COLUMN`
|
||||
- `ALTER DROP COLUMN`
|
||||
- `ALTER MODIFY COLUMN`
|
||||
- `ALTER COMMENT COLUMN`
|
||||
- `ALTER CLEAR COLUMN`
|
||||
- `ALTER RENAME COLUMN`
|
||||
- `ALTER INDEX`
|
||||
- `ALTER ORDER BY`
|
||||
- `ALTER ADD INDEX`
|
||||
- `ALTER DROP INDEX`
|
||||
- `ALTER MATERIALIZE INDEX`
|
||||
- `ALTER CLEAR INDEX`
|
||||
- `ALTER CONSTRAINT`
|
||||
- `ALTER ADD CONSTRAINT`
|
||||
- `ALTER DROP CONSTRAINT`
|
||||
- `ALTER TTL`
|
||||
- `ALTER MATERIALIZE TTL`
|
||||
- `ALTER SETTINGS`
|
||||
- `ALTER MOVE PARTITION`
|
||||
- `ALTER FETCH PARTITION`
|
||||
- `ALTER FREEZE PARTITION`
|
||||
- `ALTER VIEW`
|
||||
- `ALTER VIEW REFRESH `
|
||||
- `ALTER VIEW MODIFY QUERY`
|
||||
- [CREATE](#grant-create)
|
||||
- `CREATE DATABASE`
|
||||
- `CREATE TABLE`
|
||||
- `CREATE VIEW`
|
||||
- `CREATE DICTIONARY`
|
||||
- `CREATE TEMPORARY TABLE`
|
||||
- [DROP](#grant-drop)
|
||||
- `DROP DATABASE`
|
||||
- `DROP TABLE`
|
||||
- `DROP VIEW`
|
||||
- `DROP DICTIONARY`
|
||||
- [TRUNCATE](#grant-truncate)
|
||||
- [OPTIMIZE](#grant-optimize)
|
||||
- [SHOW](#grant-show)
|
||||
- `SHOW DATABASES`
|
||||
- `SHOW TABLES`
|
||||
- `SHOW COLUMNS`
|
||||
- `SHOW DICTIONARIES`
|
||||
- [KILL QUERY](#grant-kill-query)
|
||||
- [ACCESS MANAGEMENT](#grant-access-management)
|
||||
- `CREATE USER`
|
||||
- `ALTER USER`
|
||||
- `DROP USER`
|
||||
- `CREATE ROLE`
|
||||
- `ALTER ROLE`
|
||||
- `DROP ROLE`
|
||||
- `CREATE ROW POLICY`
|
||||
- `ALTER ROW POLICY`
|
||||
- `DROP ROW POLICY`
|
||||
- `CREATE QUOTA`
|
||||
- `ALTER QUOTA`
|
||||
- `DROP QUOTA`
|
||||
- `CREATE SETTINGS PROFILE`
|
||||
- `ALTER SETTINGS PROFILE`
|
||||
- `DROP SETTINGS PROFILE`
|
||||
- `SHOW ACCESS`
|
||||
- `SHOW_USERS`
|
||||
- `SHOW_ROLES`
|
||||
- `SHOW_ROW_POLICIES`
|
||||
- `SHOW_QUOTAS`
|
||||
- `SHOW_SETTINGS_PROFILES`
|
||||
- `ROLE ADMIN`
|
||||
- [SYSTEM](#grant-system)
|
||||
- `SYSTEM SHUTDOWN`
|
||||
- `SYSTEM DROP CACHE`
|
||||
- `SYSTEM DROP DNS CACHE`
|
||||
- `SYSTEM DROP MARK CACHE`
|
||||
- `SYSTEM DROP UNCOMPRESSED CACHE`
|
||||
- `SYSTEM RELOAD`
|
||||
- `SYSTEM RELOAD CONFIG`
|
||||
- `SYSTEM RELOAD DICTIONARY`
|
||||
- `SYSTEM RELOAD EMBEDDED DICTIONARIES`
|
||||
- `SYSTEM MERGES`
|
||||
- `SYSTEM TTL MERGES`
|
||||
- `SYSTEM FETCHES`
|
||||
- `SYSTEM MOVES`
|
||||
- `SYSTEM SENDS`
|
||||
- `SYSTEM DISTRIBUTED SENDS`
|
||||
- `SYSTEM REPLICATED SENDS`
|
||||
- `SYSTEM REPLICATION QUEUES`
|
||||
- `SYSTEM SYNC REPLICA`
|
||||
- `SYSTEM RESTART REPLICA`
|
||||
- `SYSTEM FLUSH`
|
||||
- `SYSTEM FLUSH DISTRIBUTED`
|
||||
- `SYSTEM FLUSH LOGS`
|
||||
- [INTROSPECTION](#grant-introspection)
|
||||
- `addressToLine`
|
||||
- `addressToSymbol`
|
||||
- `demangle`
|
||||
- [SOURCES](#grant-sources)
|
||||
- `FILE`
|
||||
- `URL`
|
||||
- `REMOTE`
|
||||
- `YSQL`
|
||||
- `ODBC`
|
||||
- `JDBC`
|
||||
- `HDFS`
|
||||
- `S3`
|
||||
- [dictGet](#grant-dictget)
|
||||
|
||||
Примеры того, как трактуется данная иерархия:
|
||||
|
||||
- Привилегия `ALTER` включает все остальные `ALTER*` привилегии.
|
||||
- `ALTER CONSTRAINT` включает `ALTER ADD CONSTRAINT` и `ALTER DROP CONSTRAINT`.
|
||||
|
||||
Привилегии применяются на разных уровнях. Уровень определяет синтаксис присваивания привилегии.
|
||||
|
||||
Уровни (от низшего к высшему):
|
||||
|
||||
- `COLUMN` — Привилегия присваивается для столбца, таблицы, базы данных или глобально.
|
||||
- `TABLE` — Привилегия присваивается для таблицы, базы данных или глобально.
|
||||
- `VIEW` — Привилегия присваивается для представления, базы данных или глобально.
|
||||
- `DICTIONARY` — Привилегия присваивается для словаря, базы данных или глобально.
|
||||
- `DATABASE` — Привилегия присваивается для базы данных или глобально.
|
||||
- `GLOBAL` — Привилегия присваивается только глобально.
|
||||
- `GROUP` — Группирует привилегии разных уровней. При присвоении привилегии уровня `GROUP` присваиваются только привилегии из группы в соответствии с используемым синтаксисом.
|
||||
|
||||
Примеры допустимого синтаксиса:
|
||||
|
||||
- `GRANT SELECT(x) ON db.table TO user`
|
||||
- `GRANT SELECT ON db.* TO user`
|
||||
|
||||
Примеры недопустимого синтаксиса:
|
||||
|
||||
- `GRANT CREATE USER(x) ON db.table TO user`
|
||||
- `GRANT CREATE USER ON db.* TO user`
|
||||
|
||||
Специальная привилегия [ALL](#grant-all) присваивает все привилегии пользователю или роли.
|
||||
|
||||
По умолчанию пользователь или роль не имеют привилегий.
|
||||
|
||||
Отсутствие привилегий у пользователя или роли отображается как привилегия [NONE](#grant-none).
|
||||
|
||||
Выполнение некоторых запросов требует определенного набора привилегий. Например, чтобы выполнить запрос [RENAME](misc.md#misc_operations-rename), нужны следующие привилегии: `SELECT`, `CREATE TABLE`, `INSERT` и `DROP TABLE`.
|
||||
|
||||
|
||||
### SELECT {#grant-select}
|
||||
|
||||
Разрешает выполнять запросы [SELECT](select/index.md).
|
||||
|
||||
Уровень: `COLUMN`.
|
||||
|
||||
**Описание**
|
||||
|
||||
Пользователь с данной привилегией может выполнять запросы `SELECT` над определенными столбцами из определенной таблицы и базы данных. При включении в запрос других столбцов запрос ничего не вернет.
|
||||
|
||||
Рассмотрим следующую привилегию:
|
||||
|
||||
```sql
|
||||
GRANT SELECT(x,y) ON db.table TO john
|
||||
```
|
||||
|
||||
Данная привилегия позволяет пользователю `john` выполнять выборку данных из столбцов `x` и/или `y` в `db.table`, например, `SELECT x FROM db.table`. `john` не может выполнить `SELECT z FROM db.table` или `SELECT * FROM db.table`. После обработки данных запросов ClickHouse ничего не вернет — даже `x` или `y`. Единственное исключение — если таблица содержит только столбцы `x` и `y`. В таком случае ClickHouse вернет все данные.
|
||||
|
||||
### INSERT {#grant-insert}
|
||||
|
||||
Разрешает выполнять запросы [INSERT](insert-into.md).
|
||||
|
||||
Уровень: `COLUMN`.
|
||||
|
||||
**Описание**
|
||||
|
||||
Пользователь с данной привилегией может выполнять запросы `INSERT` над определенными столбцами из определенной таблицы и базы данных. При включении в запрос других столбцов запрос не добавит никаких данных.
|
||||
|
||||
**Пример**
|
||||
|
||||
```sql
|
||||
GRANT INSERT(x,y) ON db.table TO john
|
||||
```
|
||||
|
||||
Присвоенная привилегия позволит пользователю `john` вставить данные в столбцы `x` и/или `y` в `db.table`.
|
||||
|
||||
### ALTER {#grant-alter}
|
||||
|
||||
Разрешает выполнять запросы [ALTER](alter.md) в соответствии со следующей иерархией привилегий:
|
||||
|
||||
- `ALTER`. Уровень: `COLUMN`.
|
||||
- `ALTER TABLE`. Уровень: `GROUP`
|
||||
- `ALTER UPDATE`. Уровень: `COLUMN`. Алиасы: `UPDATE`
|
||||
- `ALTER DELETE`. Уровень: `COLUMN`. Алиасы: `DELETE`
|
||||
- `ALTER COLUMN`. Уровень: `GROUP`
|
||||
- `ALTER ADD COLUMN`. Уровень: `COLUMN`. Алиасы: `ADD COLUMN`
|
||||
- `ALTER DROP COLUMN`. Уровень: `COLUMN`. Алиасы: `DROP COLUMN`
|
||||
- `ALTER MODIFY COLUMN`. Уровень: `COLUMN`. Алиасы: `MODIFY COLUMN`
|
||||
- `ALTER COMMENT COLUMN`. Уровень: `COLUMN`. Алиасы: `COMMENT COLUMN`
|
||||
- `ALTER CLEAR COLUMN`. Уровень: `COLUMN`. Алиасы: `CLEAR COLUMN`
|
||||
- `ALTER RENAME COLUMN`. Уровень: `COLUMN`. Алиасы: `RENAME COLUMN`
|
||||
- `ALTER INDEX`. Уровень: `GROUP`. Алиасы: `INDEX`
|
||||
- `ALTER ORDER BY`. Уровень: `TABLE`. Алиасы: `ALTER MODIFY ORDER BY`, `MODIFY ORDER BY`
|
||||
- `ALTER ADD INDEX`. Уровень: `TABLE`. Алиасы: `ADD INDEX`
|
||||
- `ALTER DROP INDEX`. Уровень: `TABLE`. Алиасы: `DROP INDEX`
|
||||
- `ALTER MATERIALIZE INDEX`. Уровень: `TABLE`. Алиасы: `MATERIALIZE INDEX`
|
||||
- `ALTER CLEAR INDEX`. Уровень: `TABLE`. Алиасы: `CLEAR INDEX`
|
||||
- `ALTER CONSTRAINT`. Уровень: `GROUP`. Алиасы: `CONSTRAINT`
|
||||
- `ALTER ADD CONSTRAINT`. Уровень: `TABLE`. Алиасы: `ADD CONSTRAINT`
|
||||
- `ALTER DROP CONSTRAINT`. Уровень: `TABLE`. Алиасы: `DROP CONSTRAINT`
|
||||
- `ALTER TTL`. Уровень: `TABLE`. Алиасы: `ALTER MODIFY TTL`, `MODIFY TTL`
|
||||
- `ALTER MATERIALIZE TTL`. Уровень: `TABLE`. Алиасы: `MATERIALIZE TTL`
|
||||
- `ALTER SETTINGS`. Уровень: `TABLE`. Алиасы: `ALTER SETTING`, `ALTER MODIFY SETTING`, `MODIFY SETTING`
|
||||
- `ALTER MOVE PARTITION`. Уровень: `TABLE`. Алиасы: `ALTER MOVE PART`, `MOVE PARTITION`, `MOVE PART`
|
||||
- `ALTER FETCH PARTITION`. Уровень: `TABLE`. Алиасы: `FETCH PARTITION`
|
||||
- `ALTER FREEZE PARTITION`. Уровень: `TABLE`. Алиасы: `FREEZE PARTITION`
|
||||
- `ALTER VIEW` Уровень: `GROUP`
|
||||
- `ALTER VIEW REFRESH `. Уровень: `VIEW`. Алиасы: `ALTER LIVE VIEW REFRESH`, `REFRESH VIEW`
|
||||
- `ALTER VIEW MODIFY QUERY`. Уровень: `VIEW`. Алиасы: `ALTER TABLE MODIFY QUERY`
|
||||
|
||||
Примеры того, как трактуется данная иерархия:
|
||||
|
||||
- Привилегия `ALTER` включает все остальные `ALTER*` привилегии.
|
||||
- `ALTER CONSTRAINT` включает `ALTER ADD CONSTRAINT` и `ALTER DROP CONSTRAINT`.
|
||||
|
||||
**Дополнительно**
|
||||
|
||||
- Привилегия `MODIFY SETTING` позволяет изменять настройки движков таблиц. Не влияет на настройки или конфигурационные параметры сервера.
|
||||
- Операция `ATTACH` требует наличие привилегии [CREATE](#grant-create).
|
||||
- Операция `DETACH` требует наличие привилегии [DROP](#grant-drop).
|
||||
- Для остановки мутации с помощью [KILL MUTATION](misc.md#kill-mutation-statement), необходима привилегия на выполнение данной мутации. Например, чтобы остановить запрос `ALTER UPDATE`, необходима одна из привилегий: `ALTER UPDATE`, `ALTER TABLE` или `ALTER`.
|
||||
|
||||
### CREATE {#grant-create}
|
||||
|
||||
Разрешает выполнять DDL-запросы [CREATE](create.md) и [ATTACH](misc.md#attach) в соответствии со следующей иерархией привилегий:
|
||||
|
||||
- `CREATE`. Уровень: `GROUP`
|
||||
- `CREATE DATABASE`. Уровень: `DATABASE`
|
||||
- `CREATE TABLE`. Уровень: `TABLE`
|
||||
- `CREATE VIEW`. Уровень: `VIEW`
|
||||
- `CREATE DICTIONARY`. Уровень: `DICTIONARY`
|
||||
- `CREATE TEMPORARY TABLE`. Уровень: `GLOBAL`
|
||||
|
||||
**Дополнительно**
|
||||
|
||||
- Для удаления созданной таблицы пользователю необходима привилегия [DROP](#grant-drop).
|
||||
|
||||
### DROP {#grant-drop}
|
||||
|
||||
Разрешает выполнять запросы [DROP](misc.md#drop) и [DETACH](misc.md#detach-statement) в соответствии со следующей иерархией привилегий:
|
||||
|
||||
- `DROP`. Уровень:
|
||||
- `DROP DATABASE`. Уровень: `DATABASE`
|
||||
- `DROP TABLE`. Уровень: `TABLE`
|
||||
- `DROP VIEW`. Уровень: `VIEW`
|
||||
- `DROP DICTIONARY`. Уровень: `DICTIONARY`
|
||||
|
||||
|
||||
### TRUNCATE {#grant-truncate}
|
||||
|
||||
Разрешает выполнять запросы [TRUNCATE](misc.md#truncate-statement).
|
||||
|
||||
Уровень: `TABLE`.
|
||||
|
||||
### OPTIMIZE {#grant-optimize}
|
||||
|
||||
Разрешает выполнять запросы [OPTIMIZE TABLE](misc.md#misc_operations-optimize).
|
||||
|
||||
Уровень: `TABLE`.
|
||||
|
||||
### SHOW {#grant-show}
|
||||
|
||||
Разрешает выполнять запросы `SHOW`, `DESCRIBE`, `USE` и `EXISTS` в соответствии со следующей иерархией привилегий:
|
||||
|
||||
- `SHOW`. Уровень: `GROUP`
|
||||
- `SHOW DATABASES`. Уровень: `DATABASE`. Разрешает выполнять запросы `SHOW DATABASES`, `SHOW CREATE DATABASE`, `USE <database>`.
|
||||
- `SHOW TABLES`. Уровень: `TABLE`. Разрешает выполнять запросы `SHOW TABLES`, `EXISTS <table>`, `CHECK <table>`.
|
||||
- `SHOW COLUMNS`. Уровень: `COLUMN`. Разрешает выполнять запросы `SHOW CREATE TABLE`, `DESCRIBE`.
|
||||
- `SHOW DICTIONARIES`. Уровень: `DICTIONARY`. Разрешает выполнять запросы `SHOW DICTIONARIES`, `SHOW CREATE DICTIONARY`, `EXISTS <dictionary>`.
|
||||
|
||||
**Дополнительно**
|
||||
|
||||
У пользователя есть привилегия `SHOW`, если ему присвоена любая другая привилегия по отношению к определенной таблице, словарю или базе данных.
|
||||
|
||||
|
||||
### KILL QUERY {#grant-kill-query}
|
||||
|
||||
Разрешает выполнять запросы [KILL](misc.md#kill-query-statement) в соответствии со следующей иерархией привилегий:
|
||||
|
||||
Уровень: `GLOBAL`.
|
||||
|
||||
**Дополнительно**
|
||||
|
||||
`KILL QUERY` позволяет пользователю останавливать запросы других пользователей.
|
||||
|
||||
|
||||
### ACCESS MANAGEMENT {#grant-access-management}
|
||||
|
||||
Разрешает пользователю выполнять запросы на управление пользователями, ролями и политиками доступа к строкам.
|
||||
|
||||
- `ACCESS MANAGEMENT`. Уровень: `GROUP`
|
||||
- `CREATE USER`. Уровень: `GLOBAL`
|
||||
- `ALTER USER`. Уровень: `GLOBAL`
|
||||
- `DROP USER`. Уровень: `GLOBAL`
|
||||
- `CREATE ROLE`. Уровень: `GLOBAL`
|
||||
- `ALTER ROLE`. Уровень: `GLOBAL`
|
||||
- `DROP ROLE`. Уровень: `GLOBAL`
|
||||
- `ROLE ADMIN`. Уровень: `GLOBAL`
|
||||
- `CREATE ROW POLICY`. Уровень: `GLOBAL`. Алиасы: `CREATE POLICY`
|
||||
- `ALTER ROW POLICY`. Уровень: `GLOBAL`. Алиасы: `ALTER POLICY`
|
||||
- `DROP ROW POLICY`. Уровень: `GLOBAL`. Алиасы: `DROP POLICY`
|
||||
- `CREATE QUOTA`. Уровень: `GLOBAL`
|
||||
- `ALTER QUOTA`. Уровень: `GLOBAL`
|
||||
- `DROP QUOTA`. Уровень: `GLOBAL`
|
||||
- `CREATE SETTINGS PROFILE`. Уровень: `GLOBAL`. Алиасы: `CREATE PROFILE`
|
||||
- `ALTER SETTINGS PROFILE`. Уровень: `GLOBAL`. Алиасы: `ALTER PROFILE`
|
||||
- `DROP SETTINGS PROFILE`. Уровень: `GLOBAL`. Алиасы: `DROP PROFILE`
|
||||
- `SHOW ACCESS`. Уровень: `GROUP`
|
||||
- `SHOW_USERS`. Уровень: `GLOBAL`. Алиасы: `SHOW CREATE USER`
|
||||
- `SHOW_ROLES`. Уровень: `GLOBAL`. Алиасы: `SHOW CREATE ROLE`
|
||||
- `SHOW_ROW_POLICIES`. Уровень: `GLOBAL`. Алиасы: `SHOW POLICIES`, `SHOW CREATE ROW POLICY`, `SHOW CREATE POLICY`
|
||||
- `SHOW_QUOTAS`. Уровень: `GLOBAL`. Алиасы: `SHOW CREATE QUOTA`
|
||||
- `SHOW_SETTINGS_PROFILES`. Уровень: `GLOBAL`. Алиасы: `SHOW PROFILES`, `SHOW CREATE SETTINGS PROFILE`, `SHOW CREATE PROFILE`
|
||||
|
||||
Привилегия `ROLE ADMIN` разрешает пользователю назначать и отзывать любые роли, включая те, которые не назначены пользователю с опцией администратора.
|
||||
|
||||
### SYSTEM {#grant-system}
|
||||
|
||||
Разрешает выполнять запросы [SYSTEM](system.md) в соответствии со следующей иерархией привилегий:
|
||||
|
||||
- `SYSTEM`. Уровень: `GROUP`
|
||||
- `SYSTEM SHUTDOWN`. Уровень: `GLOBAL`. Алиасы: `SYSTEM KILL`, `SHUTDOWN`
|
||||
- `SYSTEM DROP CACHE`. Алиасы: `DROP CACHE`
|
||||
- `SYSTEM DROP DNS CACHE`. Уровень: `GLOBAL`. Алиасы: `SYSTEM DROP DNS`, `DROP DNS CACHE`, `DROP DNS`
|
||||
- `SYSTEM DROP MARK CACHE`. Уровень: `GLOBAL`. Алиасы: `SYSTEM DROP MARK`, `DROP MARK CACHE`, `DROP MARKS`
|
||||
- `SYSTEM DROP UNCOMPRESSED CACHE`. Уровень: `GLOBAL`. Алиасы: `SYSTEM DROP UNCOMPRESSED`, `DROP UNCOMPRESSED CACHE`, `DROP UNCOMPRESSED`
|
||||
- `SYSTEM RELOAD`. Уровень: `GROUP`
|
||||
- `SYSTEM RELOAD CONFIG`. Уровень: `GLOBAL`. Алиасы: `RELOAD CONFIG`
|
||||
- `SYSTEM RELOAD DICTIONARY`. Уровень: `GLOBAL`. Алиасы: `SYSTEM RELOAD DICTIONARIES`, `RELOAD DICTIONARY`, `RELOAD DICTIONARIES`
|
||||
- `SYSTEM RELOAD EMBEDDED DICTIONARIES`. Уровень: `GLOBAL`. Алиасы: `RELOAD EMBEDDED DICTIONARIES`
|
||||
- `SYSTEM MERGES`. Уровень: `TABLE`. Алиасы: `SYSTEM STOP MERGES`, `SYSTEM START MERGES`, `STOP MERGES`, `START MERGES`
|
||||
- `SYSTEM TTL MERGES`. Уровень: `TABLE`. Алиасы: `SYSTEM STOP TTL MERGES`, `SYSTEM START TTL MERGES`, `STOP TTL MERGES`, `START TTL MERGES`
|
||||
- `SYSTEM FETCHES`. Уровень: `TABLE`. Алиасы: `SYSTEM STOP FETCHES`, `SYSTEM START FETCHES`, `STOP FETCHES`, `START FETCHES`
|
||||
- `SYSTEM MOVES`. Уровень: `TABLE`. Алиасы: `SYSTEM STOP MOVES`, `SYSTEM START MOVES`, `STOP MOVES`, `START MOVES`
|
||||
- `SYSTEM SENDS`. Уровень: `GROUP`. Алиасы: `SYSTEM STOP SENDS`, `SYSTEM START SENDS`, `STOP SENDS`, `START SENDS`
|
||||
- `SYSTEM DISTRIBUTED SENDS`. Уровень: `TABLE`. Алиасы: `SYSTEM STOP DISTRIBUTED SENDS`, `SYSTEM START DISTRIBUTED SENDS`, `STOP DISTRIBUTED SENDS`, `START DISTRIBUTED SENDS`
|
||||
- `SYSTEM REPLICATED SENDS`. Уровень: `TABLE`. Алиасы: `SYSTEM STOP REPLICATED SENDS`, `SYSTEM START REPLICATED SENDS`, `STOP REPLICATED SENDS`, `START REPLICATED SENDS`
|
||||
- `SYSTEM REPLICATION QUEUES`. Уровень: `TABLE`. Алиасы: `SYSTEM STOP REPLICATION QUEUES`, `SYSTEM START REPLICATION QUEUES`, `STOP REPLICATION QUEUES`, `START REPLICATION QUEUES`
|
||||
- `SYSTEM SYNC REPLICA`. Уровень: `TABLE`. Алиасы: `SYNC REPLICA`
|
||||
- `SYSTEM RESTART REPLICA`. Уровень: `TABLE`. Алиасы: `RESTART REPLICA`
|
||||
- `SYSTEM FLUSH`. Уровень: `GROUP`
|
||||
- `SYSTEM FLUSH DISTRIBUTED`. Уровень: `TABLE`. Алиасы: `FLUSH DISTRIBUTED`
|
||||
- `SYSTEM FLUSH LOGS`. Уровень: `GLOBAL`. Алиасы: `FLUSH LOGS`
|
||||
|
||||
Привилегия `SYSTEM RELOAD EMBEDDED DICTIONARIES` имплицитно присваивается привилегией `SYSTEM RELOAD DICTIONARY ON *.*`.
|
||||
|
||||
|
||||
### INTROSPECTION {#grant-introspection}
|
||||
|
||||
Разрешает использовать функции [интроспекции](../../operations/optimizing-performance/sampling-query-profiler.md).
|
||||
|
||||
- `INTROSPECTION`. Уровень: `GROUP`. Алиасы: `INTROSPECTION FUNCTIONS`
|
||||
- `addressToLine`. Уровень: `GLOBAL`
|
||||
- `addressToSymbol`. Уровень: `GLOBAL`
|
||||
- `demangle`. Уровень: `GLOBAL`
|
||||
|
||||
|
||||
### SOURCES {#grant-sources}
|
||||
|
||||
Разрешает использовать внешние источники данных. Применяется к [движкам таблиц](../../engines/table-engines/index.md) и [табличным функциям](../table-functions/index.md#table-functions).
|
||||
|
||||
- `SOURCES`. Уровень: `GROUP`
|
||||
- `FILE`. Уровень: `GLOBAL`
|
||||
- `URL`. Уровень: `GLOBAL`
|
||||
- `REMOTE`. Уровень: `GLOBAL`
|
||||
- `YSQL`. Уровень: `GLOBAL`
|
||||
- `ODBC`. Уровень: `GLOBAL`
|
||||
- `JDBC`. Уровень: `GLOBAL`
|
||||
- `HDFS`. Уровень: `GLOBAL`
|
||||
- `S3`. Уровень: `GLOBAL`
|
||||
|
||||
Привилегия `SOURCES` разрешает использование всех источников. Также вы можете присвоить привилегию для каждого источника отдельно. Для использования источников необходимы дополнительные привилегии.
|
||||
|
||||
Примеры:
|
||||
|
||||
- Чтобы создать таблицу с [движком MySQL](../../engines/table-engines/integrations/mysql.md), необходимы привилегии `CREATE TABLE (ON db.table_name)` и `MYSQL`.
|
||||
- Чтобы использовать [табличную функцию mysql](../table-functions/mysql.md), необходимы привилегии `CREATE TEMPORARY TABLE` и `MYSQL`.
|
||||
|
||||
### dictGet {#grant-dictget}
|
||||
|
||||
- `dictGet`. Алиасы: `dictHas`, `dictGetHierarchy`, `dictIsIn`
|
||||
|
||||
Разрешает вызывать функции [dictGet](../functions/ext-dict-functions.md#dictget), [dictHas](../functions/ext-dict-functions.md#dicthas), [dictGetHierarchy](../functions/ext-dict-functions.md#dictgethierarchy), [dictIsIn](../functions/ext-dict-functions.md#dictisin).
|
||||
|
||||
Уровень: `DICTIONARY`.
|
||||
|
||||
**Примеры**
|
||||
|
||||
- `GRANT dictGet ON mydb.mydictionary TO john`
|
||||
- `GRANT dictGet ON mydictionary TO john`
|
||||
|
||||
### ALL {#grant-all}
|
||||
|
||||
Присваивает пользователю или роли все привилегии на объект с регулируемым доступом.
|
||||
|
||||
|
||||
### NONE {#grant-none}
|
||||
|
||||
Не присваивает никаких привилегий.
|
||||
|
||||
|
||||
### ADMIN OPTION {#admin-option-privilege}
|
||||
|
||||
Привилегия `ADMIN OPTION` разрешает пользователю назначать свои роли другому пользователю.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/query_language/grant/) <!--hide-->
|
@ -70,7 +70,7 @@ DESC|DESCRIBE TABLE [db.]table [INTO OUTFILE filename] [FORMAT format]
|
||||
|
||||
Вложенные структуры данных выводятся в «развёрнутом» виде. То есть, каждый столбец - по отдельности, с именем через точку.
|
||||
|
||||
## DETACH {#detach}
|
||||
## DETACH {#detach-statement}
|
||||
|
||||
Удаляет из сервера информацию о таблице name. Сервер перестаёт знать о существовании таблицы.
|
||||
|
||||
@ -91,9 +91,6 @@ DETACH TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]
|
||||
DROP DATABASE [IF EXISTS] db [ON CLUSTER cluster]
|
||||
```
|
||||
|
||||
Удаляет все таблицы внутри базы данных db, а затем саму базу данных db.
|
||||
Если указано `IF EXISTS` - не выдавать ошибку, если база данных не существует.
|
||||
|
||||
``` sql
|
||||
DROP [TEMPORARY] TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]
|
||||
```
|
||||
@ -101,6 +98,68 @@ DROP [TEMPORARY] TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]
|
||||
Удаляет таблицу.
|
||||
Если указано `IF EXISTS` - не выдавать ошибку, если таблица не существует или база данных не существует.
|
||||
|
||||
## DROP USER {#drop-user-statement}
|
||||
|
||||
Удаляет пользователя.
|
||||
|
||||
### Синтаксис {#drop-user-syntax}
|
||||
|
||||
```sql
|
||||
DROP USER [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## DROP ROLE {#drop-role-statement}
|
||||
|
||||
Удаляет роль.
|
||||
|
||||
При удалении роль отзывается у всех объектов системы доступа, которым она присвоена.
|
||||
|
||||
### Синтаксис {#drop-role-syntax}
|
||||
|
||||
```sql
|
||||
DROP ROLE [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
## DROP ROW POLICY {#drop-row-policy-statement}
|
||||
|
||||
Удаляет политику доступа к строкам.
|
||||
|
||||
При удалении политика отзывается у всех объектов системы доступа, которым она присвоена.
|
||||
|
||||
### Синтаксис {#drop-row-policy-syntax}
|
||||
|
||||
``` sql
|
||||
DROP [ROW] POLICY [IF EXISTS] name [,...] ON [database.]table [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## DROP QUOTA {#drop-quota-statement}
|
||||
|
||||
Удаляет квоту.
|
||||
|
||||
При удалении квота отзывается у всех объектов системы доступа, которым она присвоена.
|
||||
|
||||
### Синтаксис {#drop-quota-syntax}
|
||||
|
||||
``` sql
|
||||
DROP QUOTA [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## DROP SETTINGS PROFILE {#drop-settings-profile-statement}
|
||||
|
||||
Удаляет профиль настроек.
|
||||
|
||||
При удалении профиль отзывается у всех объектов системы доступа, которым он присвоен.
|
||||
|
||||
### Синтаксис {#drop-settings-profile-syntax}
|
||||
|
||||
``` sql
|
||||
DROP [SETTINGS] PROFILE [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## EXISTS {#exists}
|
||||
|
||||
``` sql
|
||||
@ -109,7 +168,7 @@ EXISTS [TEMPORARY] TABLE [db.]name [INTO OUTFILE filename] [FORMAT format]
|
||||
|
||||
Возвращает один столбец типа `UInt8`, содержащий одно значение - `0`, если таблицы или БД не существует и `1`, если таблица в указанной БД существует.
|
||||
|
||||
## KILL QUERY {#kill-query}
|
||||
## KILL QUERY {#kill-query-statement}
|
||||
|
||||
``` sql
|
||||
KILL QUERY [ON CLUSTER cluster]
|
||||
@ -144,7 +203,7 @@ Readonly-пользователи могут останавливать толь
|
||||
|
||||
Тестовый вариант запроса (`TEST`) только проверяет права пользователя и выводит список запросов для остановки.
|
||||
|
||||
## KILL MUTATION {#kill-mutation}
|
||||
## KILL MUTATION {#kill-mutation-statement}
|
||||
|
||||
``` sql
|
||||
KILL MUTATION [ON CLUSTER cluster]
|
||||
@ -215,7 +274,57 @@ SET profile = 'profile-name-from-the-settings-file'
|
||||
|
||||
Подробности смотрите в разделе [Настройки](../../operations/settings/settings.md).
|
||||
|
||||
## TRUNCATE {#truncate}
|
||||
## SET ROLE {#set-role-statement}
|
||||
|
||||
Активирует роли для текущего пользователя.
|
||||
|
||||
### Синтаксис {#set-role-syntax}
|
||||
|
||||
``` sql
|
||||
SET ROLE {DEFAULT | NONE | role [,...] | ALL | ALL EXCEPT role [,...]}
|
||||
```
|
||||
|
||||
## SET DEFAULT ROLE {#set-default-role-statement}
|
||||
|
||||
Устанавливает роли по умолчанию для пользователя.
|
||||
|
||||
Роли по умолчанию активируются автоматически при входе пользователя. Ролями по умолчанию могут быть установлены только ранее назначенные роли. Если роль не назначена пользователю, ClickHouse выбрасывает исключение.
|
||||
|
||||
|
||||
### Синтаксис {#set-default-role-syntax}
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE {NONE | role [,...] | ALL | ALL EXCEPT role [,...]} TO {user|CURRENT_USER} [,...]
|
||||
```
|
||||
|
||||
|
||||
### Примеры {#set-default-role-examples}
|
||||
|
||||
Установить несколько ролей по умолчанию для пользователя:
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE role1, role2, ... TO user
|
||||
```
|
||||
|
||||
Установить ролями по умолчанию все назначенные пользователю роли:
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE ALL TO user
|
||||
```
|
||||
|
||||
Удалить роли по умолчанию для пользователя:
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE NONE TO user
|
||||
```
|
||||
|
||||
Установить ролями по умолчанию все назначенные пользователю роли за исключением указанных:
|
||||
|
||||
```sql
|
||||
SET DEFAULT ROLE ALL EXCEPT role1, role2 TO user
|
||||
```
|
||||
|
||||
## TRUNCATE {#truncate-statement}
|
||||
|
||||
``` sql
|
||||
TRUNCATE TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]
|
||||
|
@ -1 +0,0 @@
|
||||
../../../en/sql-reference/statements/revoke.md
|
43
docs/ru/sql-reference/statements/revoke.md
Normal file
43
docs/ru/sql-reference/statements/revoke.md
Normal file
@ -0,0 +1,43 @@
|
||||
# REVOKE
|
||||
|
||||
Отзывает привилегии у пользователей или ролей.
|
||||
|
||||
## Синтаксис {#revoke-syntax}
|
||||
|
||||
**Отзыв привилегий у пользователей**
|
||||
|
||||
``` sql
|
||||
REVOKE [ON CLUSTER cluster_name] privilege[(column_name [,...])] [,...] ON {db.table|db.*|*.*|table|*} FROM {user | CURRENT_USER} [,...] | ALL | ALL EXCEPT {user | CURRENT_USER} [,...]
|
||||
```
|
||||
|
||||
**Отзыв ролей у пользователей**
|
||||
|
||||
``` sql
|
||||
REVOKE [ON CLUSTER cluster_name] [ADMIN OPTION FOR] role [,...] FROM {user | role | CURRENT_USER} [,...] | ALL | ALL EXCEPT {user_name | role_name | CURRENT_USER} [,...]
|
||||
```
|
||||
|
||||
## Описание {#revoke-description}
|
||||
|
||||
Для отзыва привилегий можно использовать привилегию более широкой области действия. Например, если у пользователя есть привилегия `SELECT (x,y)`, администратор может отозвать ее с помощью одного из запросов: `REVOKE SELECT(x,y) ...`, `REVOKE SELECT * ...` или даже `REVOKE ALL PRIVILEGES ...`.
|
||||
|
||||
### Частичный отзыв {#partial-revokes-dscr}
|
||||
|
||||
Вы можете отозвать часть привилегии. Например, если у пользователя есть привилегия `SELECT *.*`, вы можете отозвать привилегию на чтение данных из какой-то таблицы или базы данных.
|
||||
|
||||
## Примеры {#revoke-example}
|
||||
|
||||
Присвоить пользователю `john` привилегию на `SELECT` из всех баз данных кроме `accounts`:
|
||||
|
||||
``` sql
|
||||
GRANT SELECT ON *.* TO john;
|
||||
REVOKE SELECT ON accounts.* FROM john;
|
||||
```
|
||||
|
||||
Присвоить пользователю `mira` привилегию на `SELECT` из всех столбцов таблицы `accounts.staff` кроме столбца `wage`:
|
||||
|
||||
``` sql
|
||||
GRANT SELECT ON accounts.staff TO mira;
|
||||
REVOKE SELECT(wage) ON accounts.staff FROM mira;
|
||||
```
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/operations/settings/settings/) <!-- hide -->
|
@ -1,4 +1,4 @@
|
||||
# Секции PREWHERE {#prewhere-clause}
|
||||
# Секция PREWHERE {#prewhere-clause}
|
||||
|
||||
Prewhere — это оптимизация для более эффективного применения фильтрации. Она включена по умолчанию, даже если секция `PREWHERE` явно не указана. В этом случае работает автоматическое перемещение части выражения из [WHERE](where.md) до стадии prewhere. Роль секции `PREWHERE` только для управления этой оптимизацией, если вы думаете, что знаете, как сделать перемещение условия лучше, чем это происходит по умолчанию.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Предложение WHERE {#select-where}
|
||||
# Секция WHERE {#select-where}
|
||||
|
||||
Позволяет задать выражение, которое ClickHouse использует для фильтрации данных перед всеми другими действиями в запросе кроме выражений, содержащихся в секции [PREWHERE](prewhere.md#select-prewhere). Обычно, это выражение с логическими операторами.
|
||||
Позволяет задать выражение, которое ClickHouse использует для фильтрации данных перед всеми другими действиями в запросе кроме выражений, содержащихся в секции [PREWHERE](prewhere.md#prewhere-clause). Обычно, это выражение с логическими операторами.
|
||||
|
||||
Результат выражения должен иметь тип `UInt8`.
|
||||
|
||||
|
@ -95,4 +95,78 @@ SHOW DICTIONARIES FROM db LIKE '%reg%' LIMIT 2
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
|
||||
|
||||
## SHOW GRANTS {#show-grants-statement}
|
||||
|
||||
Выводит привилегии пользователя.
|
||||
|
||||
### Синтаксис {#show-grants-syntax}
|
||||
|
||||
``` sql
|
||||
SHOW GRANTS [FOR user]
|
||||
```
|
||||
|
||||
Если пользователь не задан, запрос возвращает привилегии текущего пользователя.
|
||||
|
||||
|
||||
|
||||
## SHOW CREATE USER {#show-create-user-statement}
|
||||
|
||||
Выводит параметры, использованные при [создании пользователя](create.md#create-user-statement).
|
||||
|
||||
`SHOW CREATE USER` не возвращает пароль пользователя.
|
||||
|
||||
### Синтаксис {#show-create-user-syntax}
|
||||
|
||||
``` sql
|
||||
SHOW CREATE USER [name | CURRENT_USER]
|
||||
```
|
||||
|
||||
|
||||
|
||||
## SHOW CREATE ROLE {#show-create-role-statement}
|
||||
|
||||
Выводит параметры, использованные при [создании роли](create.md#create-role-statement).
|
||||
|
||||
### Синтаксис {#show-create-role-syntax}
|
||||
|
||||
``` sql
|
||||
SHOW CREATE ROLE name
|
||||
```
|
||||
|
||||
|
||||
|
||||
## SHOW CREATE ROW POLICY {#show-create-row-policy-statement}
|
||||
|
||||
Выводит параметры, использованные при [создании политики доступа к строкам](create.md#create-row-policy-statement).
|
||||
|
||||
### Синтаксис {#show-create-row-policy-syntax}
|
||||
|
||||
```sql
|
||||
SHOW CREATE [ROW] POLICY name ON [database.]table
|
||||
```
|
||||
|
||||
|
||||
## SHOW CREATE QUOTA {#show-create-quota-statement}
|
||||
|
||||
Выводит параметры, использованные при [создании квоты](create.md#create-quota-statement).
|
||||
|
||||
### Синтаксис {#show-create-row-policy-syntax}
|
||||
|
||||
```sql
|
||||
SHOW CREATE QUOTA [name | CURRENT]
|
||||
```
|
||||
|
||||
|
||||
## SHOW CREATE SETTINGS PROFILE {#show-create-settings-profile-statement}
|
||||
|
||||
Выводит параметры, использованные при [создании профиля настроек](create.md#create-settings-profile-statement).
|
||||
|
||||
### Синтаксис {#show-create-row-policy-syntax}
|
||||
|
||||
```sql
|
||||
SHOW CREATE [SETTINGS] PROFILE name
|
||||
```
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/query_language/show/) <!--hide-->
|
||||
|
@ -5,7 +5,7 @@ toc_priority: 34
|
||||
toc_title: "\u0412\u0432\u0435\u0434\u0435\u043D\u0438\u0435"
|
||||
---
|
||||
|
||||
# Табличные функции {#tablichnye-funktsii}
|
||||
# Табличные функции {#table-functions}
|
||||
|
||||
Табличные функции — это метод создания таблиц.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user