20.1. Файл pg_hba.conf#

20.1. Файл pg_hba.conf

20.1. Файл pg_hba.conf #

Вход в систему клиента контролируется конфигурационным файлом, который традиционно называется pg_hba.conf и хранится в каталоге данных кластера базы данных. (HBA означает аутентификацию на основе хоста). При инициализации каталога данных с помощью initdb устанавливается файл pg_hba.conf по умолчанию. Однако возможно размещение файла конфигурации аутентификации в другом месте; см. параметр конфигурации hba_file.

Общий формат файла pg_hba.conf состоит из набора записей, по одной на строку. Пустые строки игнорируются, а также любой текст после символа комментария #. Запись может продолжаться на следующей строке, если строка заканчивается обратной косой чертой. (Обратные косые черты не имеют специального значения, кроме случаев, когда они находятся в конце строки). Запись состоит из нескольких полей, разделенных пробелами и/или табуляцией. Поля могут содержать пробелы, если значение поля заключено в двойные кавычки. Если одно из ключевых слов в поле базы данных, пользователя или адреса (например, all или replication) заключено в кавычки, то это слово теряет свое специальное значение и просто соответствует базе данных, пользователю или хосту с таким именем. Продолжение строки с помощью обратной косой черты применяется даже внутри текста в кавычках или комментариев.

Каждая запись аутентификации указывает тип соединения, диапазон IP-адресов клиента (если это актуально для типа соединения), имя базы данных, имя пользователя и метод аутентификации, который будет использоваться для соединений, соответствующих этим параметрам. Первая запись с совпадающим типом соединения, адресом клиента, запрашиваемой базой данных и именем пользователя используется для выполнения аутентификации. Нет перехода или резервного варианта: если одна запись выбрана и аутентификация не удалась, последующие записи не рассматриваются. Если ни одна запись не совпадает, доступ запрещен.

Каждая запись может быть директивой включения или записью аутентификации. Директивы включения указывают файлы, которые могут быть включены и содержат дополнительные записи. Записи будут вставлены на место директив включения. Директивы включения содержат только два поля: директива include, include_if_exists или include_dir и файл или каталог, который нужно включить. Файл или каталог может быть указан как относительный, так и абсолютный путь, и может быть заключен в двойные кавычки. Для формы include_dir будут включены все файлы, не начинающиеся с . и оканчивающиеся на .conf. Несколько файлов в каталоге включения обрабатываются в порядке имен файлов (согласно правилам локали C, т.е. цифры перед буквами, а заглавные буквы перед строчными).

Запись может иметь несколько форматов:

local               database  user  auth-method [auth-options]
host                database  user  address     auth-method  [auth-options]
hostssl             database  user  address     auth-method  [auth-options]
hostnossl           database  user  address     auth-method  [auth-options]
hostgssenc          database  user  address     auth-method  [auth-options]
hostnogssenc        database  user  address     auth-method  [auth-options]
host                database  user  IP-address  IP-mask      auth-method  [auth-options]
hostssl             database  user  IP-address  IP-mask      auth-method  [auth-options]
hostnossl           database  user  IP-address  IP-mask      auth-method  [auth-options]
hostgssenc          database  user  IP-address  IP-mask      auth-method  [auth-options]
hostnogssenc        database  user  IP-address  IP-mask      auth-method  [auth-options]
include             file
include_if_exists   file
include_dir         directory

Значение полей следующее:

local

Эта запись соответствует попыткам подключения с использованием сокетов домена Unix. Без такой записи подключения через сокеты домена Unix запрещены.

host

Эта запись соответствует попыткам подключения, сделанным с использованием TCP/IP. Записи host соответствуют попыткам подключения с использованием SSL или без SSL, а также попыткам подключения с использованием зашифровки GSSAPI или без GSSAPI.

Примечание

Возможность удаленных TCP/IP-соединений не будет доступна, если сервер не запущен с соответствующим значением параметра конфигурации listen_addresses, так как поведение по умолчанию заключается в прослушивании TCP/IP-соединений только на локальном адресе цикла обратной связи localhost.

hostssl

Эта запись соответствует попыткам подключения, сделанным с использованием TCP/IP, но только когда подключение осуществляется с использованием шифрования SSL.

Для использования этой опции сервер должен быть построен с поддержкой SSL. Кроме того, SSL должен быть включен путем установки параметра конфигурации ssl (см. Раздел 18.9 для получения дополнительной информации). В противном случае запись hostssl игнорируется, за исключением записи предупреждения о том, что она не может соответствовать никаким соединениям.

hostnossl

Этот тип записи имеет противоположное поведение по сравнению с hostssl; он соответствует только попыткам подключения, сделанным через TCP/IP, которые не используют SSL.

hostgssenc

Эта запись соответствует попыткам подключения, сделанным с использованием TCP/IP, но только когда подключение осуществляется с использованием шифрования GSSAPI.

Для использования этой опции сервер должен быть собран с поддержкой GSSAPI. В противном случае запись hostgssenc игнорируется, за исключением записи предупреждения о том, что она не может соответствовать никаким соединениям.

hostnogssenc

Этот тип записи имеет противоположное поведение по сравнению с hostgssenc; он соответствует только попыткам подключения, сделанным через TCP/IP, не использующим шифрование GSSAPI.

database

Указывает, каким именам баз данных соответствует эта запись. Значение all указывает, что она соответствует всем базам данных. Значение sameuser указывает, что запись соответствует, если запрашиваемая база данных имеет то же имя, что и запрашиваемый пользователь. Значение samerole указывает, что запрашиваемый пользователь должен быть членом роли с тем же именем, что и запрашиваемая база данных. (samegroup является устаревшим, но все еще допустимым написанием samerole.) Суперпользователи не считаются членами роли для целей samerole, если они не являются явными членами роли, прямо или косвенно, а не просто в силу того, что они суперпользователи. Значение replication указывает, что запись соответствует, если запрашивается физическое репликационное соединение, однако, оно не соответствует логическим репликационным соединениям. Обратите внимание, что физические репликационные соединения не указывают конкретную базу данных, тогда как логические репликационные соединения указывают её. В противном случае, это имя конкретной базы данных Tantor SE или регулярное выражение. Несколько имен баз данных и/или регулярных выражений могут быть указаны, разделяя их запятыми.

Если имя базы данных начинается с косой черты (/), то оставшаяся часть имени рассматривается как регулярное выражение. (См. Раздел 9.7.3.1 для подробностей синтаксиса регулярных выражений в Tantor SE.)

Отдельный файл, содержащий имена баз данных и/или регулярные выражения, можно указать, добавив перед именем файла @.

user

Указывает, каким именам пользователей базы данных соответствует эта запись. Значение all указывает, что оно соответствует всем пользователям. В противном случае, это либо имя конкретного пользователя базы данных, регулярное выражение (начинающееся с косой черты (/), либо имя группы, предшествующее +. (Напомним, что в Tantor SE нет реального различия между пользователями и группами; метка + действительно означает соответствие любой из ролей, которые прямо или косвенно являются членами этой роли, в то время как имя без метки + соответствует только этой конкретной роли.) Для этой цели суперпользователь считается членом роли только в том случае, если он явно является членом роли, прямо или косвенно, а не просто в силу того, что он суперпользователь. Несколько имен пользователей и/или регулярных выражений могут быть указаны, разделяя их запятыми.

Если имя пользователя начинается с косой черты (/), то оставшаяся часть имени рассматривается как регулярное выражение. (См. Раздел 9.7.3.1 для подробностей синтаксиса регулярных выражений Tantor SE.)

Отдельный файл, содержащий имена пользователей и/или регулярные выражения, можно указать, добавив перед именем файла @.

address

Указывает адрес(а) клиентской машины, с которыми соответствует данная запись. Это поле может содержать имя хоста, диапазон IP-адресов или одно из специальных ключевых слов, упомянутых ниже.

Диапазон IP-адресов указывается с использованием стандартной числовой нотации для начального адреса диапазона, затем символа слэш (/) и длины маски CIDR. Длина маски указывает количество старших битов IP-адреса клиента, которые должны совпадать. Биты справа от этого должны быть нулевыми в заданном IP-адресе. Между IP-адресом, символом слэш (/) и длиной маски CIDR не должно быть пробелов.

Примеры типичного задания диапазона IPv4-адресов в этом формате: 172.20.143.89/32 для одного хоста, или 172.20.143.0/24 для небольшой сети, или 10.6.0.0/16 для более крупной сети. Диапазон IPv6-адресов может выглядеть так: ::1/128 для одного хоста (в данном случае это адрес петли IPv6), или fe80::7a31:c1ff:0000:0000/96 для небольшой сети. 0.0.0.0/0 представляет все IPv4-адреса, а ::0/0 представляет все IPv6-адреса. Для указания одного хоста используйте длину маски 32 для IPv4 или 128 для IPv6. В сетевом адресе не пропускать конечные нули.

Запись, заданная в формате IPv4, будет соответствовать только соединениям IPv4, а запись, заданная в формате IPv6, будет соответствовать только соединениям IPv6, даже если представленное адресное пространство находится в диапазоне IPv4-в-IPv6.

Также можно написать all, чтобы сопоставить любой IP-адрес, samehost, чтобы сопоставить любой из собственных IP-адресов сервера, или samenet, чтобы сопоставить любой адрес в любой подсети, с которой сервер напрямую связан.

Если указано имя хоста (любое, что не является диапазоном IP-адресов или специальным ключевым словом, рассматривается как имя хоста), это имя сравнивается с результатом обратного разрешения имени IP-адреса клиента (например, обратного DNS-поиска, если используется DNS). Сравнение имен хостов не чувствительно к регистру. Если есть совпадение, то выполняется прямое разрешение имени (например, прямой DNS-поиск) для проверки, совпадает ли какой-либо из адресов, к которым разрешается имя хоста, с IP-адресом клиента. Если оба направления совпадают, то запись считается совпадающей. (Имя хоста, которое используется в pg_hba.conf, должно быть тем, которое возвращает разрешение имени адреса IP клиента, в противном случае строка не будет сопоставлена. Некоторые базы данных имен хостов позволяют связывать IP-адрес с несколькими именами хостов, но операционная система вернет только одно имя хоста при запросе разрешения IP-адреса).

Спецификация имени хоста, начинающаяся с точки (.), соответствует суффиксу фактического имени хоста. Таким образом, .example.com будет соответствовать foo.example.com (но не просто example.com).

Когда имена хостов указываются в файле pg_hba.conf, убедитесь, что разрешение имен происходит достаточно быстро. Может быть полезно настроить локальный кеш разрешения имен, такой как nscd. Также вы можете захотеть включить параметр конфигурации log_hostname, чтобы видеть имя хоста клиента вместо IP-адреса в журнале.

Эти поля не применимы к local записям.

Примечание

Пользователи иногда задаются вопросом, почему имена хостов обрабатываются таким сложным образом, с двумя разрешениями имени, включая обратный запрос IP-адреса клиента. Это усложняет использование функции в случае, если обратная запись DNS клиента не настроена или возвращает нежелательное имя хоста. Это делается прежде всего для повышения эффективности: таким образом, попытка подключения требует не более двух запросов разрешения, одного обратного и одного прямого. Если возникает проблема с разрешением для некоторого адреса, это становится проблемой только этого клиента. Гипотетическая альтернативная реализация, которая выполняла бы только прямые запросы, должна была бы разрешать каждое имя хоста, указанное в файле CPU, при каждой попытке подключения. Это могло бы быть довольно медленным, если перечислено много имен. И если возникает проблема с разрешением для одного из имен хостов, это становится проблемой для всех.

Также, для реализации функции сопоставления суффиксов необходимо выполнить обратный поиск, поскольку фактическое имя клиентского хоста должно быть известно для его сопоставления с шаблоном.

Обратите внимание, что такое поведение согласуется с другими популярными реализациями контроля доступа на основе имени хоста, такими как Apache HTTP Server и TCP Wrappers.

IP-address
IP-mask

Эти два поля могут быть использованы в качестве альтернативы для IP-адреса/mask-length обозначения. Вместо указания длины маски, фактическая маска указывается в отдельном столбце. Например, 255.0.0.0 представляет собой IPv4 длину маски CIDR 8, а 255.255.255.255 представляет собой длину маски CIDR 32.

Эти поля не применимы к local записям.

auth-method

Определяет метод аутентификации, который будет использоваться при соединении, соответствующем данной записи. Возможные варианты кратко описаны здесь; подробности приведены в разделе Раздел 20.3. Все варианты указываются в нижнем регистре и учитывают регистр, поэтому даже аббревиатуры, такие как ldap, должны быть указаны в нижнем регистре.

trust

Разрешить подключение без ограничений. Этот метод позволяет любому, кто может подключиться к серверу базы данных Tantor SE, войти в систему от имени любого пользователя Tantor SE, без необходимости вводить пароль или проходить аутентификацию. Подробности см. в разделе Раздел 20.4.

reject

Отклонить соединение безусловно. Это полезно для фильтрации определенных хостов из группы, например, строка reject может блокировать подключение определенного хоста, в то время как позднее строка позволяет остальным хостам в определенной сети подключаться.

scram-sha-256

Выполнить аутентификацию SCRAM-SHA-256 для проверки пароля пользователя. См. Раздел 20.5 для получения подробной информации.

md5

Выполнить аутентификацию SCRAM-SHA-256 или MD5, чтобы проверить пароль пользователя. См. Раздел 20.5 для получения подробной информации.

password

Требовать от клиента предоставить незашифрованный пароль для аутентификации. Поскольку пароль отправляется в открытом виде по сети, это не следует использовать в ненадежных сетях. См. Раздел 20.5 для получения подробной информации.

gss

Использовать GSSAPI для аутентификации пользователя. Это доступно только для TCP/IP соединений. См. Раздел 20.6 для получения подробной информации. Он может использоваться совместно с шифрованием GSSAPI.

sspi

Использовать SSPI для аутентификации пользователя. Это доступно только в Windows. См. Раздел 20.7 для получения подробной информации.

ident

Получить имя пользователя операционной системы клиента, связавшись с сервером идентификации на клиенте и проверьте, совпадает ли оно с запрошенным именем пользователя базы данных. Аутентификация идентификации может использоваться только для соединений TCP/IP. При указании для локальных соединений будет использоваться аутентификация по пиру. См. Раздел 20.8 для получения подробной информации.

peer

Получить имя пользователя операционной системы клиента из операционной системы и проверьте, совпадает ли оно с запрошенным именем пользователя базы данных. Это доступно только для локальных подключений. См. Раздел 20.9 для получения дополнительной информации.

ldap

Аутентификация с использованием сервера LDAP. См. Раздел 20.10 для получения подробной информации.

radius

Аутентификация с использованием сервера RADIUS. См. Раздел 20.11 для получения подробной информации.

cert

Аутентификация с использованием клиентских сертификатов SSL. См. Раздел 20.12 для получения подробной информации.

pam

Аутентификация с использованием сервиса Pluggable Authentication Modules (PAM), предоставляемого операционной системой. См. Раздел 20.13 для получения подробной информации.

bsd

Аутентификация с использованием службы аутентификации BSD, предоставляемой операционной системой. См. Раздел 20.14 для получения подробной информации.

auth-options

После поля auth-method может следовать поле(я) в формате name=value, которые указывают параметры для метода аутентификации. Подробности о доступных параметрах для каждого метода аутентификации приведены ниже.

В дополнение к указанным ниже специфическим для метода параметрам, существует метод-независимый параметр аутентификации clientcert, который может быть указан в любой записи hostssl. Этот параметр может быть установлен в значение verify-ca или verify-full. Оба варианта требуют от клиента предоставления действительного (доверенного) SSL-сертификата, в то время как verify-full также требует, чтобы cn (общее имя) в сертификате совпадало с именем пользователя или применимым отображением. Это поведение аналогично методу аутентификации cert (см. Раздел 20.12), но позволяет совместно использовать проверку клиентских сертификатов с любым методом аутентификации, поддерживающим записи hostssl.

На любой записи, использующей аутентификацию клиентского сертификата (т.е. одну, использующую метод аутентификации cert или опцию clientcert), вы можете указать, какую часть учетных данных клиентского сертификата сопоставлять, используя опцию clientname. Эта опция может иметь одно из двух значений. Если вы укажете clientname=CN, что является значением по умолчанию, имя пользователя будет сопоставлено с Common Name (CN) сертификата. Если вместо этого вы укажете clientname=DN, имя пользователя будет сопоставлено с полным Distinguished Name (DN) сертификата. Эта опция, вероятно, лучше всего используется в сочетании с картой имен пользователей. Сравнение выполняется с DN в формате RFC 2253. Чтобы увидеть DN клиентского сертификата в этом формате, выполните

openssl x509 -in myclient.crt -noout -subject -nameopt RFC2253 | sed "s/^subject=//"

Необходимо быть осторожным при использовании этой опции, особенно при использовании регулярных выражений для сопоставления с DN.

include

Эта строка будет заменена содержимым данного файла.

include_if_exists

Эта строка будет заменена содержимым данного файла, если файл существует. В противном случае, в журнал будет записано сообщение, указывающее, что файл был пропущен.

include_dir

Эта строка будет заменена содержимым всех файлов, найденных в каталоге, если они не начинаются с . и не заканчиваются на .conf, обработанных в порядке имен файлов (согласно правилам локали C, т.е. цифры перед буквами, а заглавные буквы перед строчными).

Файлы, включенные с помощью конструкций @, считываются как списки имен, которые могут быть разделены пробелами или запятыми. Комментарии вводятся с помощью символа #, так же, как в файле pg_hba.conf, и разрешены вложенные конструкции @. Если имя файла, следующее за @, не является абсолютным путем, оно считается относительным путем к каталогу, содержащему ссылочный файл.

Поскольку записи pg_hba.conf рассматриваются последовательно для каждой попытки подключения, порядок записей имеет значение. Обычно, более ранние записи будут иметь более строгие параметры соединения и слабые методы аутентификации, в то время как более поздние записи будут иметь более свободные параметры соединения и более сильные методы аутентификации. Например, может понадобиться использовать аутентификацию trust для локальных TCP/IP-соединений, но требовать пароль для удаленных TCP/IP-соединений. В этом случае запись, указывающая аутентификацию trust для соединений с 127.0.0.1, будет появляться перед записью, указывающей аутентификацию с паролем для более широкого диапазона разрешенных IP-адресов клиентов.

Файл pg_hba.conf считывается при запуске и когда основной процесс сервера получает сигнал SIGHUP signal. Если вы редактируете файл на активной системе, вам потребуется отправить сигнал постмастеру (используя pg_ctl reload, вызывая SQL-функцию pg_reload_conf() или используя kill -HUP), чтобы он перечитал файл.

Примечание

Предыдущее утверждение не является верным в операционной системе Microsoft Windows: там любые изменения в файле pg_hba.conf немедленно применяются при последующих новых подключениях.

Системное представление pg_hba_file_rules может быть полезным для предварительного тестирования изменений в файле pg_hba.conf или для диагностики проблем, если загрузка файла не дала желаемого эффекта. Строки в представлении с ненулевыми полями error указывают на проблемы в соответствующих строках файла.

Подсказка

Для подключения к определенной базе данных пользователь должен пройти проверку файла pg_hba.conf и иметь привилегию CONNECT для этой базы данных. Если нужно ограничить, какие пользователи могут подключаться к каким базам данных, обычно проще контролировать это, предоставляя/отзывая привилегию CONNECT, чем указывать правила в записях файла pg_hba.conf.

Некоторые примеры записей pg_hba.conf показаны в Пример 20.1. См. следующий раздел для получения подробной информации о различных методах аутентификации.

Пример 20.1. Пример записей pg_hba.conf

# Allow any user on the local system to connect to any database with
# any database user name using Unix-domain sockets (the default for local
# connections).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     trust

# The same using local loopback TCP/IP connections.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             127.0.0.1/32            trust

# The same as the previous line, but using a separate netmask column
#
# TYPE  DATABASE        USER            IP-ADDRESS      IP-MASK             METHOD
host    all             all             127.0.0.1       255.255.255.255     trust

# The same over IPv6.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             ::1/128                 trust

# The same using a host name (would typically cover both IPv4 and IPv6).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             localhost               trust

# The same using a regular expression for DATABASE, that allows connection
# to any databases with a name beginning with "db" and finishing with a
# number using two to four digits (like "db1234" or "db12").
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    "/^db\d{2,4}$"  all             localhost               trust

# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    postgres        all             192.168.93.0/24         ident

# Allow any user from host 192.168.12.10 to connect to database
# "postgres" if the user's password is correctly supplied.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    postgres        all             192.168.12.10/32        scram-sha-256

# Allow any user from hosts in the example.com domain to connect to
# any database if the user's password is correctly supplied.
#
# Require SCRAM authentication for most users, but make an exception
# for user 'mike', who uses an older client that doesn't support SCRAM
# authentication.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             mike            .example.com            md5
host    all             all             .example.com            scram-sha-256

# In the absence of preceding "host" lines, these three lines will
# reject all connections from 192.168.54.1 (since that entry will be
# matched first), but allow GSSAPI-encrypted connections from anywhere else
# on the Internet.  The zero mask causes no bits of the host IP address to
# be considered, so it matches any host.  Unencrypted GSSAPI connections
# (which "fall through" to the third line since "hostgssenc" only matches
# encrypted GSSAPI connections) are allowed, but only from 192.168.12.10.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             192.168.54.1/32         reject
hostgssenc all          all             0.0.0.0/0               gss
host    all             all             192.168.12.10/32        gss

# Allow users from 192.168.x.x hosts to connect to any database, if
# they pass the ident check.  If, for example, ident says the user is
# "bryanh" and he requests to connect as PostgreSQL user "guest1", the
# connection is allowed if there is an entry in pg_ident.conf for map
# "omicron" that says "bryanh" is allowed to connect as "guest1".
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             192.168.0.0/16          ident map=omicron

# If these are the only four lines for local connections, they will
# allow local users to connect only to their own databases (databases
# with the same name as their database user name) except for users whose
# name end with "helpdesk", administrators and members of role "support",
# who can connect to all databases.  The file $PGDATA/admins contains a
# list of names of administrators.  Passwords are required in all cases.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   sameuser        all                                     md5
local   all             /^.*helpdesk$                           md5
local   all             @admins                                 md5
local   all             +support                                md5

# The last two lines above can be combined into a single line:
local   all             @admins,+support                        md5

# The database column can also use lists and file names:
local   db1,db2,@demodbs  all                                   md5