To check access, DNS query is performed, and all returned IP-addresses are compared to peer address.
-`<host_regexp>` — Regular expression for hostnames.
Example, `^server\d\d-\d\d-\d\.yandex\.ru$`
To check access, [DNS PTR query](https://en.wikipedia.org/wiki/Reverse_DNS_lookup) is performed for peer address and then regexp is applied. Then, for result of PTR query, another DNS query is performed and all received addresses compared to peer address. Strongly recommended that regexp is ends with $
All results of DNS requests are cached till server restart.
**Examples**
To open access for user from any network, specify:
```
<ip>::/0</ip>
```
!!! warning "Warning"
It's insecure to open access from any network, unless you have a firewall properly configured or server is not directly connected to Internet.
To open access only from localhost, specify:
```
<ip>::1</ip>
<ip>127.0.0.1</ip>
```
### user_name/profile
You can assign a settings profile for the user. Settings profiles are configured in a separate section of the `users.xml` file. For more information see the [Profiles of Settings](settings_profiles.md).
### user_name/quota
Quotas allow you to limit resource usage over a period of time, or track the use of resources. Quotas are configured in the `quotas`
section of the `users.xml` configuration file.
You can assign a quotas set for the user. For the detailed description of quotas configuration see the [Quotas](../quotas.md#quotas) section.
### user_name/databases
In this section you can you can limit rows that are returned by ClickHouse for `SELECT` queries of current user, thus implementing basic row level security.
**Example**
The following configuration sets that the user `user1` can see only the rows of `table1` as a result of `SELECT` query where the value of field `id` equals to 1000.
```
<user1>
<databases>
<database_name>
<table1>
<filter>id = 1000</filter>
</table1>
</database_name>
</databases>
</user1>
```
The `filter` can be any expression resulting with the [UInt8](../../data_types/int_uint.md)-typed value. It usually contains comparisons and logical operators. Rows from `database_name.table1` where filter results to 0 are not returned for this user. The filtering is incompatible with `PREWHERE` operations and disables `WHERE→PREWHERE` optimization.