mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-10 09:32:06 +00:00
CLICKHOUSEDOCS-558: Resolved conflicts after #10606
This commit is contained in:
Sergei Shtykov
parent
8e2747d4b0
commit
7400be8552
@ -1,111 +1,147 @@
|
||||
---
|
||||
toc_priority: 48
|
||||
toc_title: Access Rights
|
||||
toc_title: Access Control and Account Management
|
||||
---
|
||||
|
||||
# Access Rights {#access-rights}
|
||||
# Access Control and Account Management {#access-control}
|
||||
|
||||
Users and access rights are set up in the user config. This is usually `users.xml`.
|
||||
ClickHouse supports access control management based on [RBAC](https://en.wikipedia.org/wiki/Role-based_access_control) approach.
|
||||
|
||||
Users are recorded in the `users` section. Here is a fragment of the `users.xml` file:
|
||||
ClickHouse access entities:
|
||||
- [User account](#user-account-management)
|
||||
- [Role](#role-management)
|
||||
- [Row Policy](#row-policy-management)
|
||||
- [Settings Profile](#settings-profiles-management)
|
||||
- [Quota](#quotas-management)
|
||||
|
||||
``` xml
|
||||
<!-- Users and ACL. -->
|
||||
<users>
|
||||
<!-- If the user name is not specified, the 'default' user is used. -->
|
||||
<default>
|
||||
<!-- Password could be specified in plaintext or in SHA256 (in hex format).
|
||||
You can configure access entities using:
|
||||
|
||||
If you want to specify password in plaintext (not recommended), place it in 'password' element.
|
||||
Example: <password>qwerty</password>.
|
||||
Password could be empty.
|
||||
- SQL-driven workflow.
|
||||
|
||||
If you want to specify SHA256, place it in 'password_sha256_hex' element.
|
||||
Example: <password_sha256_hex>65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5</password_sha256_hex>
|
||||
You need to [enable](#enabling-access-control) this functionality.
|
||||
|
||||
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>
|
||||
- Server [configuration files](configuration-files.md) `users.xml` and `config.xml`.
|
||||
|
||||
<!-- A list of networks that access is allowed from.
|
||||
Each list item has one of the following forms:
|
||||
<ip> The IP address or subnet mask. For example: 198.51.100.0/24 or 2001:DB8::/32.
|
||||
<host> Host name. For example: example01. A DNS query is made for verification, and all addresses obtained are compared with the address of the customer.
|
||||
<host_regexp> Regular expression for host names. For example, ^example\d\d-\d\d-\d\.host\.ru$
|
||||
To check it, a DNS PTR request is made for the client's address and a regular expression is applied to the result.
|
||||
Then another DNS query is made for the result of the PTR query, and all received address are compared to the client address.
|
||||
We strongly recommend that the regex ends with \.host\.ru$.
|
||||
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.
|
||||
|
||||
If you are installing ClickHouse yourself, specify here:
|
||||
<networks>
|
||||
<ip>::/0</ip>
|
||||
</networks>
|
||||
-->
|
||||
<networks incl="networks" />
|
||||
!!! note "Warning"
|
||||
You can't manage the same access entity by both configuration methods simultaneously.
|
||||
|
||||
<!-- Settings profile for the user. -->
|
||||
<profile>default</profile>
|
||||
|
||||
<!-- Quota for the user. -->
|
||||
<quota>default</quota>
|
||||
</default>
|
||||
## Usage {#access-control-usage}
|
||||
|
||||
<!-- For requests from the Yandex.Metrica user interface via the API for data on specific counters. -->
|
||||
<web>
|
||||
<password></password>
|
||||
<networks incl="networks" />
|
||||
<profile>web</profile>
|
||||
<quota>default</quota>
|
||||
<allow_databases>
|
||||
<database>test</database>
|
||||
</allow_databases>
|
||||
<allow_dictionaries>
|
||||
<dictionary>test</dictionary>
|
||||
</allow_dictionaries>
|
||||
</web>
|
||||
</users>
|
||||
```
|
||||
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.
|
||||
|
||||
You can see a declaration from two users: `default`and`web`. We added the `web` user separately.
|
||||
If you just start using ClickHouse, you can use the following scenario:
|
||||
|
||||
The `default` user is chosen in cases when the username is not passed. The `default` user is also used for distributed query processing, if the configuration of the server or cluster doesn’t specify the `user` and `password` (see the section on the [Distributed](../engines/table-engines/special/distributed.md) engine).
|
||||
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`).
|
||||
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.
|
||||
|
||||
The user that is used for exchanging information between servers combined in a cluster must not have substantial restrictions or quotas – otherwise, distributed queries will fail.
|
||||
### Properties of Current Solution {#access-control-properties}
|
||||
|
||||
The password is specified in clear text (not recommended) or in SHA-256. The hash isn’t salted. In this regard, you should not consider these passwords as providing security against potential malicious attacks. Rather, they are necessary for protection from employees.
|
||||
- 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.
|
||||
|
||||
A list of networks is specified that access is allowed from. In this example, the list of networks for both users is loaded from a separate file (`/etc/metrika.xml`) containing the `networks` substitution. Here is a fragment of it:
|
||||
## User account {#user-account-management}
|
||||
|
||||
``` xml
|
||||
<yandex>
|
||||
...
|
||||
<networks>
|
||||
<ip>::/64</ip>
|
||||
<ip>203.0.113.0/24</ip>
|
||||
<ip>2001:DB8::/32</ip>
|
||||
...
|
||||
</networks>
|
||||
</yandex>
|
||||
```
|
||||
A user account is an access entity that allows to authorize someone in ClickHouse. A user account contains:
|
||||
|
||||
You could define this list of networks directly in `users.xml`, or in a file in the `users.d` directory (for more information, see the section “[Configuration files](configuration-files.md#configuration_files)”).
|
||||
- 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.
|
||||
- Assigned settings profiles.
|
||||
|
||||
The config includes comments explaining how to open access from everywhere.
|
||||
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.
|
||||
|
||||
For use in production, only specify `ip` elements (IP addresses and their masks), since using `host` and `hoost_regexp` might cause extra latency.
|
||||
Management queries:
|
||||
|
||||
Next the user settings profile is specified (see the section “[Settings profiles](settings/settings-profiles.md)”. You can specify the default profile, `default'`. 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. Then specify the quota to be used (see the section “[Quotas](quotas.md#quotas)”). You can specify the default quota: `default`. It is set in the config by default to only count resource usage, without restricting it. The quota can have any name. You can specify the same quota for different users – in this case, resource usage is calculated for each user individually.
|
||||
- [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)
|
||||
|
||||
In the optional `<allow_databases>` section, you can also specify a list of databases that the user can access. By default, all databases are available to the user. You can specify the `default` database. In this case, the user will receive access to the database by default.
|
||||
### Settings Applying {#access-control-settings-applying}
|
||||
|
||||
In the optional `<allow_dictionaries>` section, you can also specify a list of dictionaries that the user can access. By default, all dictionaries are available to the user.
|
||||
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):
|
||||
|
||||
Access to the `system` database is always allowed (since this database is used for processing queries).
|
||||
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.
|
||||
4. Settings applied to all the server by default or from the [default profile](server-configuration-parameters/settings.md#default-profile).
|
||||
|
||||
The user can get a list of all databases and tables in them by using `SHOW` queries or system tables, even if access to individual databases isn’t allowed.
|
||||
|
||||
Database access is not related to the [readonly](settings/permissions-for-queries.md#settings_readonly) setting. You can’t grant full access to one database and `readonly` access to another one.
|
||||
## Role {#role-management}
|
||||
|
||||
Role is a container for access entities that can be granted to a user account.
|
||||
|
||||
Role contains:
|
||||
|
||||
- [Privileges](../sql-reference/statements/grant.md#grant-privileges)
|
||||
- Settings and constraints
|
||||
- List of granted roles
|
||||
|
||||
Management queries:
|
||||
|
||||
- [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)
|
||||
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
||||
Management queries:
|
||||
|
||||
- [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 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.
|
||||
|
||||
Management queries:
|
||||
|
||||
- [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)
|
||||
|
||||
|
||||
## Quota {#quotas-management}
|
||||
|
||||
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.
|
||||
|
||||
Management queries:
|
||||
|
||||
- [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)
|
||||
|
||||
|
||||
## Enabling SQL-driven Access Control and Account Management {#enabling-access-control}
|
||||
|
||||
- Setup a directory for configurations storage.
|
||||
|
||||
ClickHouse stores access entity configurations in the folder set in the [access_control_path](server-configuration-parameters/settings.md#access_control_path) server configuration parameter.
|
||||
|
||||
- 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 of 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.
|
||||
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/operations/access_rights/) <!--hide-->
|
||||
|
||||
@ -891,4 +891,15 @@ The update is performed asynchronously, in a separate system thread.
|
||||
|
||||
**Default value**: 15.
|
||||
|
||||
|
||||
## access_control_path {#access_control_path}
|
||||
|
||||
Path to a folder where a ClickHouse server stores user and role configurations created by SQL commands.
|
||||
|
||||
Default value: `/var/lib/clickhouse/access/`.
|
||||
|
||||
**See also**
|
||||
|
||||
- [Access Control and Account Management](../access-rights.md#access-control)
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/operations/server_configuration_parameters/settings/) <!--hide-->
|
||||
|
||||
@ -8,7 +8,7 @@ toc_title: Settings Profiles
|
||||
A settings profile is a collection of settings grouped under the same name.
|
||||
|
||||
!!! note "Information"
|
||||
ClickHouse also supports [SQL-driven workflow](../access_rights.md#access-control) for managing settings profiles. We recommend using it.
|
||||
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.
|
||||
|
||||
@ -7,6 +7,10 @@ toc_title: User Settings
|
||||
|
||||
The `users` section of the `user.xml` configuration file contains user settings.
|
||||
|
||||
!!! note "Information"
|
||||
ClickHouse also supports [SQL-driven workflow](../access-rights.md#access-control) for managing users. We recommend using it.
|
||||
|
||||
|
||||
Structure of the `users` section:
|
||||
|
||||
``` xml
|
||||
@ -17,6 +21,8 @@ Structure of the `users` section:
|
||||
<!-- Or -->
|
||||
<password_sha256_hex></password_sha256_hex>
|
||||
|
||||
<access_management>0|1</access_management>
|
||||
|
||||
<networks incl="networks" replace="replace">
|
||||
</networks>
|
||||
|
||||
@ -68,6 +74,17 @@ Password can be specified in plaintext or in SHA256 (hex format).
|
||||
|
||||
The first line of the result is the password. The second line is the corresponding double SHA1 hash.
|
||||
|
||||
### 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.
|
||||
|
||||
Possible values:
|
||||
|
||||
- 0 — Disabled.
|
||||
- 1 — Enabled.
|
||||
|
||||
Default value: 0.
|
||||
|
||||
### user\_name/networks {#user-namenetworks}
|
||||
|
||||
List of networks from which the user can connect to the ClickHouse server.
|
||||
|
||||
@ -499,4 +499,107 @@ A mutation query returns immediately after the mutation entry is added (in case
|
||||
|
||||
Entries for finished mutations are not deleted right away (the number of preserved entries is determined by the `finished_mutations_to_keep` storage engine parameter). Older mutation entries are deleted.
|
||||
|
||||
## ALTER USER {#alter-user-statement}
|
||||
|
||||
Changes ClickHouse user accounts.
|
||||
|
||||
### Syntax {#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'] [,...]
|
||||
```
|
||||
|
||||
### Description {#alter-user-dscr}
|
||||
|
||||
To use `ALTER USER` you must have the [ALTER USER](grant.md#grant-access-management) privilege.
|
||||
|
||||
### Examples {#alter-user-examples}
|
||||
|
||||
Set granted roles as default:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE role1, role2
|
||||
```
|
||||
|
||||
If roles aren't previously granted to a user, ClickHouse throws an exception.
|
||||
|
||||
Set all the granted 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.
|
||||
|
||||
Set all the granted roles to default excepting `role1` and `role2`:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2
|
||||
```
|
||||
|
||||
|
||||
## ALTER ROLE {#alter-role-statement}
|
||||
|
||||
Changes roles.
|
||||
|
||||
### Syntax {#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}
|
||||
|
||||
Changes row policy.
|
||||
|
||||
### Syntax {#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}
|
||||
|
||||
Changes quotas.
|
||||
|
||||
### Syntax {#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}
|
||||
|
||||
Changes quotas.
|
||||
|
||||
### Syntax {#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'] [,...]
|
||||
```
|
||||
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/query_language/alter/) <!--hide-->
|
||||
|
||||
@ -298,6 +298,209 @@ External dictionary structure consists of attributes. Dictionary attributes are
|
||||
|
||||
Depending on dictionary [layout](../../sql-reference/dictionaries/external-dictionaries/external-dicts-dict-layout.md) one or more attributes can be specified as dictionary keys.
|
||||
|
||||
For more information, see [External Dictionaries](../../sql-reference/dictionaries/external-dictionaries/external-dicts.md) section.
|
||||
For more information, see [External Dictionaries](../dictionaries/external-dictionaries/external-dicts.md) section.
|
||||
|
||||
## CREATE USER {#create-user-statement}
|
||||
|
||||
Creates a [user account](../../operations/access-rights.md#user-account-management).
|
||||
|
||||
### Syntax {#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'] [,...]
|
||||
```
|
||||
|
||||
#### Identification
|
||||
|
||||
There are multiple ways of user identification:
|
||||
|
||||
- `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'`
|
||||
|
||||
#### 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:
|
||||
|
||||
- `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 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.
|
||||
|
||||
Another way of specifying host is to use `@` syntax with the user name. 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.
|
||||
|
||||
|
||||
### Examples {#create-user-examples}
|
||||
|
||||
|
||||
Create the user account `mira` protected by the password `qwerty`:
|
||||
|
||||
```sql
|
||||
CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty'
|
||||
```
|
||||
|
||||
`mira` should start client app at the host where the ClickHouse server runs.
|
||||
|
||||
Create the user account `john`, assign roles to it and make this roles default:
|
||||
|
||||
``` sql
|
||||
CREATE USER john DEFAULT ROLE role1, role2
|
||||
```
|
||||
|
||||
Create the user account `john` and make all his future roles default:
|
||||
|
||||
``` sql
|
||||
ALTER USER user DEFAULT ROLE ALL
|
||||
```
|
||||
|
||||
When some role will be 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`:
|
||||
|
||||
``` sql
|
||||
ALTER USER john DEFAULT ROLE ALL EXCEPT role1, role2
|
||||
```
|
||||
|
||||
|
||||
## CREATE ROLE {#create-role-statement}
|
||||
|
||||
Creates a [role](../../operations/access-rights.md#role-management).
|
||||
|
||||
### Syntax {#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'] [,...]
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
### Examples {#create-role-examples}
|
||||
|
||||
```sql
|
||||
CREATE ROLE accountant;
|
||||
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`:
|
||||
|
||||
```sql
|
||||
GRANT accountant TO mira;
|
||||
```
|
||||
|
||||
After the role is granted, the user can use it and perform the allowed queries. For example:
|
||||
|
||||
```sql
|
||||
SET ROLE accountant;
|
||||
SELECT * FROM db.*;
|
||||
```
|
||||
|
||||
## CREATE ROW POLICY {#create-row-policy-statement}
|
||||
|
||||
Creates a [filter for rows](../../operations/access-rights.md#row-policy-management), which a user can read from a table.
|
||||
|
||||
### Syntax {#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 [,...]}]
|
||||
```
|
||||
|
||||
#### Section AS {#create-row-policy-as}
|
||||
|
||||
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 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`.
|
||||
|
||||
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`
|
||||
|
||||
### Examples
|
||||
|
||||
- `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}
|
||||
|
||||
Creates a [quota](../../operations/access-rights.md#quota-management) that can be assigned to a user or a role.
|
||||
|
||||
### Syntax {#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 [,...]}]
|
||||
```
|
||||
|
||||
### Example {#create-quota-example}
|
||||
|
||||
Limit the maximum number of queries for the current user with 123 queries in 15 months constraint:
|
||||
|
||||
``` sql
|
||||
CREATE QUOTA qA FOR INTERVAL 15 MONTH MAX QUERIES 123 TO CURRENT_USER
|
||||
```
|
||||
|
||||
|
||||
## CREATE SETTINGS PROFILE {#create-settings-profile-statement}
|
||||
|
||||
Creates a [settings profile](../../operations/access-rights.md#settings-profile-management) that can be assigned to a user or a role.
|
||||
|
||||
### Syntax {#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'] [,...]
|
||||
```
|
||||
|
||||
# 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`:
|
||||
|
||||
``` sql
|
||||
CREATE SETTINGS PROFILE max_memory_usage_profile SETTINGS max_memory_usage = 100000001 MIN 90000000 MAX 110000000 TO robin
|
||||
```
|
||||
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/query_language/create/) <!--hide-->
|
||||
|
||||
@ -237,7 +237,7 @@ This privilege allows `john` to perform any `SELECT` query that involves data fr
|
||||
|
||||
### INSERT {#grant-insert}
|
||||
|
||||
Allows performing [INSERT](insert_into.md) queries.
|
||||
Allows performing [INSERT](insert-into.md) queries.
|
||||
|
||||
Privilege level: `COLUMN`.
|
||||
|
||||
@ -426,7 +426,7 @@ The `SYSTEM RELOAD EMBEDDED DICTIONARIES` privilege implicitly granted by the `S
|
||||
|
||||
### INTROSPECTION {#grant-introspection}
|
||||
|
||||
Allows using [introspection](../../operations/optimizing_performance/sampling_query_profiler.md) functions.
|
||||
Allows using [introspection](../../operations/optimizing-performance/sampling-query-profiler.md) functions.
|
||||
|
||||
- `INTROSPECTION`. Level: `GROUP`. Aliases: `INTROSPECTION FUNCTIONS`
|
||||
- `addressToLine`. Level: `GLOBAL`
|
||||
@ -436,7 +436,7 @@ Allows using [introspection](../../operations/optimizing_performance/sampling_qu
|
||||
|
||||
### SOURCES {#grant-sources}
|
||||
|
||||
Allows using external data sources. Applies to [table engines](../../engines/table_engines/index.md) and [table functions](../table_functions/index.md).
|
||||
Allows using external data sources. Applies to [table engines](../../engines/table-engines/index.md) and [table functions](../table-functions/index.md).
|
||||
|
||||
- `SOURCES`. Level: `GROUP`
|
||||
- `FILE`. Level: `GLOBAL`
|
||||
@ -452,14 +452,14 @@ The `SOURCES` privilege enables use of all the sources. Also you can grant a pri
|
||||
|
||||
Examples:
|
||||
|
||||
- To create a table with the [MySQL table engine](../../engines/table_engines/integrations/mysql.md), you need `CREATE TABLE (ON db.table_name)` and `MYSQL` privileges.
|
||||
- To use the [mysql table function](../table_functions/mysql.md), you need `CREATE TEMPORARY TABLE` and `MYSQL` privileges.
|
||||
- To create a table with the [MySQL table engine](../../engines/table-engines/integrations/mysql.md), you need `CREATE TABLE (ON db.table_name)` and `MYSQL` privileges.
|
||||
- To use the [mysql table function](../table-functions/mysql.md), you need `CREATE TEMPORARY TABLE` and `MYSQL` privileges.
|
||||
|
||||
### dictGet {#grant-dictget}
|
||||
|
||||
- `dictGet`. Aliases: `dictHas`, `dictGetHierarchy`, `dictIsIn`
|
||||
|
||||
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.
|
||||
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`.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
toc_priority: 39
|
||||
toc_priority: 41
|
||||
toc_title: Other
|
||||
---
|
||||
|
||||
@ -75,7 +75,7 @@ Returns the following `String` type columns:
|
||||
|
||||
Nested data structures are output in “expanded” format. Each column is shown separately, with the name after a dot.
|
||||
|
||||
## DETACH {#detach}
|
||||
## DETACH {#detach-statement}
|
||||
|
||||
Deletes information about the ‘name’ table from the server. The server stops knowing about the table’s existence.
|
||||
|
||||
@ -111,7 +111,69 @@ If `IF EXISTS` is specified, it doesn’t return an error if the table doesn’t
|
||||
Delets the dictionary.
|
||||
If `IF EXISTS` is specified, it doesn’t return an error if the table doesn’t exist or the database doesn’t exist.
|
||||
|
||||
## EXISTS {#exists}
|
||||
## DROP USER {#drop-user-statement}
|
||||
|
||||
Deletes a user.
|
||||
|
||||
### Syntax {#drop-user-syntax}
|
||||
|
||||
```sql
|
||||
DROP USER [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## DROP ROLE {#drop-role-statement}
|
||||
|
||||
Deletes a role.
|
||||
|
||||
Deleted role is revoked from all the entities where it was granted.
|
||||
|
||||
### Syntax {#drop-role-syntax}
|
||||
|
||||
```sql
|
||||
DROP ROLE [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
## DROP ROW POLICY {#drop-row-policy-statement}
|
||||
|
||||
Deletes a row policy.
|
||||
|
||||
Deleted row policy is revoked from all the entities where it was assigned.
|
||||
|
||||
### Syntax {#drop-row-policy-syntax}
|
||||
|
||||
``` sql
|
||||
DROP [ROW] POLICY [IF EXISTS] name [,...] ON [database.]table [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## DROP QUOTA {#drop-quota-statement}
|
||||
|
||||
Deletes a quota.
|
||||
|
||||
Deleted quota is revoked from all the entities where it was assigned.
|
||||
|
||||
### Syntax {#drop-quota-syntax}
|
||||
|
||||
``` sql
|
||||
DROP QUOTA [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## DROP SETTINGS PROFILE {#drop-settings-profile-statement}
|
||||
|
||||
Deletes a quota.
|
||||
|
||||
Deleted quota is revoked from all the entities where it was assigned.
|
||||
|
||||
### Syntax {#drop-settings-profile-syntax}
|
||||
|
||||
``` sql
|
||||
DROP [SETTINGS] PROFILE [IF EXISTS] name [,...] [ON CLUSTER cluster_name]
|
||||
```
|
||||
|
||||
|
||||
## EXISTS {#exists-statement}
|
||||
|
||||
``` sql
|
||||
EXISTS [TEMPORARY] [TABLE|DICTIONARY] [db.]name [INTO OUTFILE filename] [FORMAT format]
|
||||
@ -119,7 +181,7 @@ EXISTS [TEMPORARY] [TABLE|DICTIONARY] [db.]name [INTO OUTFILE filename] [FORMAT
|
||||
|
||||
Returns a single `UInt8`-type column, which contains the single value `0` if the table or database doesn’t exist, or `1` if the table exists in the specified database.
|
||||
|
||||
## KILL QUERY {#kill-query}
|
||||
## KILL QUERY {#kill-query-statement}
|
||||
|
||||
``` sql
|
||||
KILL QUERY [ON CLUSTER cluster]
|
||||
@ -154,7 +216,7 @@ The response contains the `kill_status` column, which can take the following val
|
||||
|
||||
A test query (`TEST`) only checks the user’s rights and displays a list of queries to stop.
|
||||
|
||||
## KILL MUTATION {#kill-mutation}
|
||||
## KILL MUTATION {#kill-mutation-statement}
|
||||
|
||||
``` sql
|
||||
KILL MUTATION [ON CLUSTER cluster]
|
||||
@ -227,7 +289,58 @@ SET profile = 'profile-name-from-the-settings-file'
|
||||
|
||||
For more information, see [Settings](../../operations/settings/settings.md).
|
||||
|
||||
## TRUNCATE {#truncate}
|
||||
## SET ROLE {#set-role-statement}
|
||||
|
||||
Activates roles for the current user.
|
||||
|
||||
### Syntax {#set-role-syntax}
|
||||
|
||||
``` sql
|
||||
SET ROLE {DEFAULT | NONE | role [,...] | ALL | ALL EXCEPT role [,...]}
|
||||
```
|
||||
|
||||
## SET DEFAULT ROLE {#set-default-role-statement}
|
||||
|
||||
Sets default roles to a user.
|
||||
|
||||
Default roles are automatically activated at user login. You can set as default only the previously granted roles. If the role isn't granted to a user, ClickHouse throws an exception.
|
||||
|
||||
|
||||
### Syntax {#set-default-role-syntax}
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE {NONE | role [,...] | ALL | ALL EXCEPT role [,...]} TO {user|CURRENT_USER} [,...]
|
||||
```
|
||||
|
||||
|
||||
### Examples {#set-default-role-examples}
|
||||
|
||||
Set multiple default roles to a user:
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE role1, role2, ... TO user
|
||||
```
|
||||
|
||||
Set all the granted roles as default to a user:
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE ALL TO user
|
||||
```
|
||||
|
||||
Purge default roles from a user:
|
||||
|
||||
``` sql
|
||||
SET DEFAULT ROLE NONE TO user
|
||||
```
|
||||
|
||||
Set all the granted roles as default excepting some of them:
|
||||
|
||||
```sql
|
||||
SET DEFAULT ROLE ALL EXCEPT role1, role2 TO user
|
||||
```
|
||||
|
||||
|
||||
## TRUNCATE {#truncate-statement}
|
||||
|
||||
``` sql
|
||||
TRUNCATE TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster]
|
||||
|
||||
@ -100,4 +100,78 @@ SHOW DICTIONARIES FROM db LIKE '%reg%' LIMIT 2
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
|
||||
|
||||
## SHOW GRANTS {#show-grants-statement}
|
||||
|
||||
Shows privileges for a user.
|
||||
|
||||
### Syntax {#show-grants-syntax}
|
||||
|
||||
``` sql
|
||||
SHOW GRANTS [FOR user]
|
||||
```
|
||||
|
||||
If user is not specified, the query returns privileges for the current user.
|
||||
|
||||
|
||||
|
||||
## SHOW CREATE USER {#show-create-user-statement}
|
||||
|
||||
Shows parameters that were used at a [user creation](create.md#create-user-statement).
|
||||
|
||||
`SHOW CREATE USER` doesn't output user passwords.
|
||||
|
||||
### Syntax {#show-create-user-syntax}
|
||||
|
||||
``` sql
|
||||
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)
|
||||
|
||||
### Syntax {#show-create-role-syntax}
|
||||
|
||||
``` sql
|
||||
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)
|
||||
|
||||
### Syntax {#show-create-row-policy-syntax}
|
||||
|
||||
```sql
|
||||
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)
|
||||
|
||||
### Syntax {#show-create-row-policy-syntax}
|
||||
|
||||
```sql
|
||||
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)
|
||||
|
||||
### Syntax {#show-create-row-policy-syntax}
|
||||
|
||||
```sql
|
||||
SHOW CREATE [SETTINGS] PROFILE name
|
||||
```
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/query_language/show/) <!--hide-->
|
||||
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/grant.md
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/revoke.md
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/grant.md
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/revoke.md
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/grant.md
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/revoke.md
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/grant.md
|
||||
@ -1 +0,0 @@
|
||||
../../../en/sql_reference/statements/revoke.md
|
||||
@ -1,2 +0,0 @@
|
||||
# GRANT
|
||||
|
||||
@ -1 +0,0 @@
|
||||
# REVOKE
|
||||
Loading…
Reference in New Issue
Block a user