wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Пользователь по умолчанию postgresql: Пароль пользователя postgres — как задать и изменить пароль

alexxlab
No Comments

Содержание

Пароль пользователя postgres — как задать и изменить пароль

Пароль пользователя postgres задается при добавлении пользователя изначально, обе операции выполняются одной командой . Потом пароль поменять.

 

 

Команды по администрированию базами и пользователями выполняются от имени системного пользователя postgres

root может стать им выполнив su — postgres

Затем можно без пароля попасть в интерфейс БД psql

 

Или то же самое одной командой

sudo -u postgres psql

Пользователь может создать базу

=# create database db1;

 

Затем добавить пользователя и задать для него пароль

=# create user appadmin with encrypted password ‘jdfh8jhtghnjkfrvhyu’;

 

После этого пользователю нужно дать права для работы с базой данных

=#  grant all privileges on db1 mydb to appadmin;

 

Изменить пароль пользователя Postgres

Пользователя можно создавать и задавать ему пароль двумя раздельными командами

sudo -u postgres createuser anotheruser

Вторая служит для изменения паролей уже существующих пользователей, выполняется из консоли psql

=# alter user anotheruser with encrypted password ‘NEW_STRONG_PASSWORD’;

 

Непосредственно для системного пользователя postgres пароль не нужен, им может стать root выполнив su как показано ранее. Если нужна авторизация root может установить для postgres новый пароль

 

passwd postgres

Затем пароль нужно ввести дважды, отображаться он не будет.

 

Пользователь appadmin — не системный, он существует только в postgresql.

Подключаться к базе из консоли от имени этого пользователя нужно указывая имя базы и ключ -W

 

psql -h myhost -d db1 -U appadmin -W

Последний ключ не обязателен, но без него в интерактивном режиме в некоторых версиях СУБД не будет запрашиваться пароль, пароль должен запрашиваться.

 

Про создание дампов баз данных Postgres и их загрузку.

PostgreSQL : Документация: 12: 19.11. Параметры клиентских сеансов по умолчанию : Компания Postgres Professional

client_min_messages (enum)

Управляет минимальным уровнем сообщений, посылаемых клиенту. Допустимые значения DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING и ERROR. Каждый из перечисленных уровней включает все идущие после него. Чем дальше в этом списке уровень сообщения, тем меньше сообщений будет посылаться клиенту. По умолчанию используется NOTICE. Обратите внимание, позиция LOG здесь отличается от принятой в log_min_messages.

Сообщения уровня INFO передаются клиенту всегда.

search_path (string)

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

Значением search_path должен быть список имён схем через запятую. Если для имени, указанного в этом списке, не находится существующая схема, либо пользователь не имеет права USAGE для схемы с этим именем, такое имя просто игнорируется.

Если список содержит специальный элемент $user, вместо него подставляется схема с именем, возвращаемым функцией CURRENT_USER, если такая схема существует и пользователь имеет право USAGE для неё. (В противном случае элемент $user игнорируется.)

Схема системных каталогов, pg_catalog, просматривается всегда, независимо от того, указана она в пути или нет. Если она указана в пути, она просматривается в заданном порядке. Если же pg_catalog отсутствует в пути, эта схема будет просматриваться перед остальными элементами пути.

Аналогично всегда просматривается схема временных таблиц текущего сеанса, pg_temp_nnn, если она существует. Её можно включить в путь поиска, указав её псевдоним pg_temp. Если она отсутствует в пути, она будет просматриваться первой (даже перед pg_catalog). Временная схема просматривается только при поиске отношений (таблиц, представлений, последовательностей и т. д.) и типов данных, но никогда при поиске функций и операторов.

Когда объекты создаются без указания определённой целевой схемы, они помещаются в первую пригодную схему, указанную в search_path. Если путь поиска схем пуст, выдаётся ошибка.

По умолчанию этот параметр имеет значение "$user", public. При таком значении поддерживается совместное использование базы данных (когда пользователи не имеют личных схем, все используют схему public), использование личных схем, а также комбинация обоих вариантов. Другие подходы можно реализовать, изменяя значение пути по умолчанию, либо глобально, либо индивидуально для каждого пользователя.

Более подробно обработка схем описана в Разделе 5.9. В частности, стандартная конфигурация схем подходит только для баз данных с одним пользователем или с взаимно доверяющими пользователями.

Текущее действующее значение пути поиска можно получить, воспользовавшись SQL-функцией current_schemas (см. Раздел 9.25). Это значение может отличаться от значения search_path, так как current_schemas показывает, как были преобразованы элементы, фигурирующие в search_path.

row_security (boolean)

Эта переменная определяет, должна ли выдаваться ошибка при применении политик защиты строк. Со значением on политики применяются в обычном режиме. Со значением off запросы, ограничиваемые минимум одной политикой, будут выдавать ошибку. Значение по умолчанию — on. Значение off рекомендуется, когда ограничение видимости строк чревато некорректными результатами; например, pg_dump устанавливает это значение. Эта переменная не влияет на роли, которые обходят все политики защиты строк, а именно, на суперпользователей и роли с атрибутом BYPASSRLS.

Подробнее о политиках защиты строк можно узнать в описании CREATE POLICY.

default_table_access_method (string)

Этот параметр задаёт табличный метод доступа по умолчанию, который будет использоваться при создании таблиц или материализованных представлений, если в команде CREATE не будет явно указан метод доступа, или при выполнении команды SELECT ... INTO, в которой явно задать метод доступа нельзя. Значение по умолчанию — heap.

default_tablespace (string)

Эта переменная устанавливает табличное пространство по умолчанию, в котором будут создаваться объекты (таблицы и индексы), когда в команде CREATE табличное пространство не указывается явно. В заданном табличном пространстве впоследствии будут создаваться также секции секционируемых отношений.

Её значением может быть либо имя табличного пространства, либо пустая строка, подразумевающая использование табличного пространства по умолчанию в текущей базе данных. Если табличное пространство с заданным именем не существует, PostgreSQL будет автоматически использовать табличное пространство по умолчанию. Если используется не пространство по умолчанию, пользователь должен иметь право CREATE для него, иначе он не сможет создавать объекты.

Эта переменная не используется для временных таблиц; для них задействуется temp_tablespaces.

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

За дополнительными сведениями о табличных пространствах обратитесь к Разделу 22.6.

temp_tablespaces (string)

Эта переменная задаёт табличные пространства, в которых будут создаваться временные объекты (временные таблицы и индексы временных таблиц), когда в команде CREATE табличное пространство не указывается явно. В этих табличных пространствах также создаются временные файлы для внутреннего использования, например, для сортировки больших наборов данных.

Её значение содержит список имён табличных пространств. Когда этот список содержит больше одного имени, PostgreSQL выбирает из этого списка случайный элемент при создании каждого временного объекта; однако при создании последующих объектов внутри транзакции табличные пространства перебираются последовательно. Если в этом списке оказывается пустая строка, PostgreSQL будет автоматически использовать вместо этого элемента табличное пространство по умолчанию для текущей базы данных.

Когда temp_tablespaces задаётся интерактивно, указание несуществующего табличного пространства считается ошибкой, как и указание табличного пространства, для которого пользователь не имеет права CREATE. Однако при использовании значения, заданного ранее, несуществующие табличные пространства и пространства, для которых у пользователя нет права CREATE, просто игнорируются. В частности, это касается значения, заданного в postgresql.conf.

По умолчанию значение этой переменной — пустая строка. С таким значением все временные объекты создаются в табличном пространстве по умолчанию, установленном для текущей базы данных.

См. также default_tablespace.

check_function_bodies (boolean)

Этот параметр обычно включён. Выключение этого параметра (присвоение ему значения off) отключает проверку строки с телом функции, передаваемой команде CREATE FUNCTION. Отключение проверки позволяет избежать побочных эффектов процесса проверки и исключить ложные срабатывания из-за таких проблем, как ссылки вперёд. Этому параметру нужно присваивать значение off перед загрузкой функций от лица других пользователей; pg_dump делает это автоматически.

default_transaction_isolation (enum)

Для каждой транзакции в SQL устанавливается уровень изоляции: «read uncommitted», «read committed», «repeatable read» или «serializable». Этот параметр задаёт уровень изоляции, который будет устанавливаться по умолчанию для новых транзакций. Значение этого параметра по умолчанию — «read committed».

Дополнительную информацию вы можете найти в Главе 13 и SET TRANSACTION.

default_transaction_read_only (boolean)

SQL-транзакции в режиме «только чтение» не могут модифицировать не временные таблицы. Этот параметр определяет, будут ли новые транзакции по умолчанию иметь характеристику «только чтение». Значение этого параметра по умолчанию — off (допускается чтение и запись).

За дополнительной информацией обратитесь к SET TRANSACTION.

default_transaction_deferrable (boolean)

Транзакция, работающая на уровне изоляции serializable, в режиме «только чтение» может быть задержана, прежде чем будет разрешено её выполнение. Однако, когда она начинает выполняться, для обеспечения сериализуемости не требуется никаких дополнительных усилий, так что коду сериализации ни при каких условиях не придётся прерывать её из-за параллельных изменений, поэтому это вполне подходит для длительных транзакций в режиме «только чтение».

Этот параметр определяет, будет ли каждая новая транзакция по умолчанию откладываемой. В настоящее время его действие не распространяется на транзакции, для которых устанавливается режим «чтение/запись» или уровень изоляции ниже serializable. Значение по умолчанию — off (выкл.).

За дополнительной информацией обратитесь к SET TRANSACTION.

session_replication_role (enum)

Управляет срабатыванием правил и триггеров, связанных с репликацией, в текущем сеансе. Изменение этой переменной требует наличия прав суперпользователя и приводит к сбросу всех ранее кешированных планов запросов. Она может принимать следующие значения: origin (значение по умолчанию), replica и local.

Предполагается, что системы логической репликации будут устанавливать для него значение replica, применяя реплицированные изменения. В результате триггеры и правила (с конфигурацией по умолчанию) не будут срабатывать в репликах. Подробнее об этом говорится в описании предложений ENABLE TRIGGER и ENABLE RULE команды ALTER TABLE.

Внутри PostgreSQL значения origin и local воспринимаются как равнозначные. Сторонние системы репликации могут различать их для своих внутренних целей, например, отмечать значением local сеанс, изменения в котором не должны реплицироваться.

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

statement_timeout (integer)

Задаёт максимальную длительность выполнения оператора, при превышении которой оператор прерывается. Если log_min_error_statement имеет значение ERROR или ниже, оператор, прерванный по тайм-ауту, будет также записан в журнал. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. При значении, равном нулю (по умолчанию), этот контроль длительности отключается.

Длительность выполнения отсчитывается с момента получения команды сервером до завершения её выполнения. В расширенном протоколе запросов время тайм-аута отсчитывается с момента получения любого связанного с запросом сообщения (Parse, Bind, Execute, Describe), а прерывание происходит на стадии обработки сообщений Execute или Sync.

Устанавливать значение statement_timeout в postgresql.conf не рекомендуется, так как это повлияет на все сеансы.

lock_timeout (integer)

Задаёт максимальную длительность ожидания любым оператором получения блокировки таблицы, индекса, строки или другого объекта базы данных. Если ожидание не закончилось за указанное время, оператор прерывается. Это ограничение действует на каждую попытку получения блокировки по отдельности и применяется как к явным запросам блокировки (например, LOCK TABLE или SELECT FOR UPDATE без NOWAIT), так и к неявным. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. При значении, равном нулю (по умолчанию), этот контроль длительности отключается.

В отличие от statement_timeout, этот тайм-аут может произойти только при ожидании блокировки. Заметьте, что при ненулевом statement_timeout бессмысленно задавать в lock_timeout такое же или большее значение, так как тайм-аут оператора всегда будет происходить раньше. Если log_min_error_statement имеет значение ERROR или ниже, оператор, прерванный по тайм-ауту, будет записан в журнал.

Устанавливать значение lock_timeout в postgresql.conf не рекомендуется, так как это повлияет на все сеансы.

idle_in_transaction_session_timeout (integer)

Завершать любые сеансы, в которых открытая транзакция простаивает дольше заданного времени. Это позволяет освободить все блокировки сеанса и вновь задействовать слот подключения; также это позволяет очистить кортежи, видимые только для этой транзакции. Подробнее это описано в Разделе 24.1.

Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. При значении, равном нулю (по умолчанию), этот контроль длительности отключается.

vacuum_freeze_table_age (integer)

Задаёт максимальный возраст для поля pg_class.relfrozenxid таблицы, при достижении которого VACUUM будет производить агрессивное сканирование. Агрессивное сканирование отличается от обычного сканирования VACUUM тем, что затрагивает все страницы, которые могут содержать незамороженные XID или MXID, а не только те, что могут содержать мёртвые кортежи. Значение по умолчанию — 150 миллионов транзакций. Хотя пользователи могут задать любое значение от нуля до двух миллиардов, в VACUUM введён внутренний предел для действующего значения, равный 95% от autovacuum_freeze_max_age, чтобы периодически запускаемая вручную команда VACUUM имела шансы выполниться, прежде чем для таблицы будет запущена автоочистка для предотвращения зацикливания. За дополнительными сведениями обратитесь к Подразделу 24.1.5.

vacuum_freeze_min_age (integer)

Задаёт возраст для отсечки (в транзакциях), при достижении которого команда VACUUM должна замораживать версии строк при сканировании таблицы. Значение по умолчанию — 50 миллионов транзакций. Хотя пользователи могут задать любое значение от нуля до одного миллиарда, в VACUUM введён внутренний предел для действующего значения, равный половине autovacuum_freeze_max_age, чтобы принудительная автоочистка выполнялась не слишком часто. За дополнительными сведениями обратитесь к Подразделу 24.1.5.

vacuum_multixact_freeze_table_age (integer)

Задаёт максимальный возраст для поля pg_class.relminmxid таблицы, при достижении которого команда VACUUM будет выполнять агрессивное сканирование. Агрессивное сканирование отличается от обычного сканирования VACUUM тем, что затрагивает все страницы, которые могут содержать незамороженные XID или MXID, а не только те, что могут содержать мёртвые кортежи. Значение по умолчанию — 150 миллионов мультитранзакций. Хотя пользователи могут задать любое значение от нуля до двух миллиардов, в VACUUM введён внутренний предел для действующего значения, равный 95% от autovacuum_multixact_freeze_max_age, чтобы периодически запускаемая вручную команда VACUUM имела шансы выполниться, прежде чем для таблицы будет запущена автоочистка для предотвращения зацикливания. За дополнительными сведениями обратитесь к Подразделу 24.1.5.1.

vacuum_multixact_freeze_min_age (integer)

Задаёт возраст для отсечки (в мультитранзакциях), при достижении которого команда VACUUM должна заменять идентификаторы мультитранзакций новыми идентификаторами транзакций или мультитранзакций при сканировании таблицы. Значение по умолчанию — 5 миллионов мультитранзакций. Хотя пользователи могут задать любое значение от нуля до одного миллиарда, в VACUUM введён внутренний предел для действующего значения, равный половине autovacuum_multixact_freeze_max_age, чтобы принудительная автоочистка не выполнялась слишком часто. За дополнительными сведениями обратитесь к Подразделу 24.1.5.1.

vacuum_cleanup_index_scale_factor (floating point)

Определяет процент от общего числа кортежей кучи, подсчитанных при последнем сборе статистики, который может быть вставлен без необходимости сканирования индекса на стадии очистки при выполнении VACUUM. В настоящее время этот параметр применяется только к индексам-B-деревьям.

Если из кучи не удалялись кортежи, индексы-B-деревья будут в любом случае сканироваться на стадии очистки VACUUM, когда выполняется хотя бы одно из следующих условий: статистика индексов устарела; индекс содержит удалённые страницы, которые могут быть переработаны при очистке. Статистика индекса считается уста

Установка Postgresql и указание пароля


PostgreSQL — это объектно-реляционная система баз данных, которая обладает признаками традиционной коммерческой базы данных, с расширениями, которые будут доступны следующему поколению СУБД (систем управления базами данных).

Установка

Для установки PostgreSQL выполните следующую команду в терминале:

sudo apt-get install postgresql



sudo apt-get install postgresql

Сразу после установки вы можете настроить сервер PostgreSQL по вашим потребностям, хотя стандартная настройка вполне жизнеспособна.

Настройка

По умолчанию соединения через TCP/IP заблокированы. PostgreSQL поддерживает множество методов аутентификации. Метод аутентификации IDENT используется для postgres и локальных пользователей пока не настроено что-то еще. Обратитесь к PostgreSQL Administrator’s Guide, если вы собираетесь использовать какую-либо альтернативу типа Kerberos.

Дальнейшее обсуждение предполагает, что вы собираетесь разрешить соединения по TCP/IP и используете аутентификацию клиентов на основе метода MD5. Файлы настроек PostgreSQL хранятся в каталоге /etc/postgresql/<version>/main. Например, если вы установили PostgreSQL 8.4, файлы настроек сохранятся в каталоге /etc/postgresql/8.4/main.

Для настройки аутентификации ident добавьте записи в файл /etc/postgresql/8.4/main/pg_ident.conf. В файле содержатся подробные комментарии чтобы направлять вас.

Чтобы разрешить соединения по TCP/IP, отредактируйте файл /etc/postgresql/8.4/main/postgresql.conf. Найдите строку

#listen_addresses = ‘localhost’



#listen_addresses = ‘localhost’

и замените ее на:

listen_addresses = ‘localhost’



listen_addresses = ‘localhost’

Чтобы разрешить другим компьютерам соединяться с вашим PostgreSQL сервером, замените ‘localhost’ на IP адрес вашего сервера или в качестве альтернативы на 0.0.0.0, чтобы подключить все интерфейсы.


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

Теперь, поскольку мы можем подключиться к нашему серверу PostgreSQL, следующим шагом будет установка пароля для пользователя postgres. Выполните следующую команду в терминале для соединения со стандартной базой шаблонов PostgreSQL:

sudo -u postgres psql template1



sudo -u postgres psql template1

Эта команда подключится к PostgreSQL базе данных template1 как пользователь postgres. После подключения к серверу PostgreSQL вы окажетесь в SQL консоли. Вы можете выполнить следующую SQL команду в консоли psql для настройки пароля пользователя postgres:

ALTER USER postgres with encrypted password ‘your_password’;



ALTER USER postgres with encrypted password ‘your_password’;

После настройки пароля, измените файл /etc/postgresql/8.4/main/pg_hba.conf на использование MD5 аутентификации для пользователя postgres:

local all postgres md5



local   all         postgres                          md5

Под конец вам потребуется перезапустить сервис PostgreSQL для применения новых настроек. Из терминала выполните следующее для перезапуска PostgreSQL:

sudo /etc/init.d/postgresql-8.4 restart



sudo /etc/init.d/postgresql-8.4 restart

Настройка выше в любом случае неполная. Пожалуйста обратитесь к руководству PostgreSQL Administrator’s Guide для настройки других параметров.

Ссылки


Установка и первоначальная настройка PostgreSQL

1. Установка

1.1. Установка из официального репозитория

Если для Вас важна последняя доступная версия PostgreSQL (если нет, я советую Вам хорошенько подумать), то Вам необходимо установить ее из официального репозитория PostgreSQL. Сделать это можно, следуя официальной инструкции. Затем, следует обновить пакеты:


$ sudo apt-get update

И  установить PostgreSQL командой:


$ sudo apt-get install postgresql-x.x
  • x.x — необходимая версия

Список всех доступных версий можно посмотреть командой:


$ sudo apt-cache search postgresql

1.2. Установка из репозитория ОС

Установка PostgreSQL из репозитория ОС производится путем добавления двух основных пакетов:


$ sudo apt-get install postgresql postgresql-contrib

2. Консоль PostgreSQL

Все доступные операции над базами данных и пользователями производится из консоли psql.

2.1. Вход в консоль

Для начала необходимо войти в систему от пользователя postgres, это возможно только с правами root:


# su - postgres

Пользователь postgres — это своеобразный суперпользователь для базы данных PostgreSQL. Затем, из-под пользователя postgres можно войти в консоль:


$ psql

Или проще, сразу входим в консоль psql под пользователем postgres:


$ sudo -u postgres psql

2.2. Выход из консоли

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


postgres=# \q

И, если это необходимо, уходим от пользователя postgres:


$ exit

3. Пользователи PostgreSQL

Рекомендуется для каждой базы данных создать независимую прослойку, создав нового пользователя, и только ему дать права к управлению ей. Манипуляции с пользователями производятся с консоли psql.

3.1. Создание пользователя

Тут все достаточно просто:


# CREATE USER username WITH PASSWORD '12345';
  • username — логин нового пользователя

  • ‘12345’ — Пароль пользователя. Вводится в кавычках

3.2. Удаление пользователя

Тут еще проще:


# DROP USER username;
  • username — логин пользователя, которого необходимо удалить.

4. Базы данных

Все манипуляции с базой данных также производятся в консоли psql.

4.1. Создание базы данных

Тут все также, как при создании пользователя:


# CREATE DATABASE dbname;
  • dbname — имя создаваемой базы данных

4.2. Удаление базы данных


# DROP DATABASE dbname;
  • dbname — имя удаляемой базы данных

Прошу заметить, что база данных откажется удаляться в определенных случаях:

  • Если имеются пользователи с правами на эту базу. Перед удалением базы данных их права необходимо отозвать. Об этом далее.

  • Если имеется хотя бы одна незакрытая сессия соединения с базой данных. В этом случае сессии необходимо будет закрыть. В крайнем случае, можно просто остановить сервера, взаимодействующие с этой базой данных на момент ее удаления (хотя, смысла их запускать после удаления базы данных мало)

4.3. Назначение прав пользователям

Наличие базы данных и пользователей в системе PostgreSQL само по себе не дает результатов. Для корректной работы определенного пользователя с определенной базой данных, ему необходимо назначить права на работу с ней. Для этого выполняем комманду:


# GRANT ALL PRIVILEGES ON DATABASE dbname TO username;
  • dbname — имя базы данных, права над работой которой необходимо дать доступ

  • username — имя пользователя, которому будут предоставлены права над указанной базой данных

4.4. Удаление прав пользователей

Иногда, возникает необходимость сменить пользователя, управляющего базой данных, или просто отозвать права для ее последующего удаления. Рекомендую не пренебрегать этой командой и действовать по принципу “Один пользователь управляет одной базой данных”.


# REVOKE ALL PRIVILEGES ON DATABASE dbname FROM username;
  • dbname — имя базы данных, права над работой которой необходимо отозвать

  • username — имя польователя, права которого необходимо отозвать

PostgreSQL : Документация: 10: 20.3. Методы аутентификации : Компания Postgres Professional

20.3. Методы аутентификации

Следующие подразделы содержат более детальную информацию о методах аутентификации.

20.3.1. Аутентификация trust

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

Аутентификация trust очень удобна для локальных подключений на однопользовательской рабочей станции. Но сам по себе этот метод обычно не подходит для машин с несколькими пользователями. Однако вы можете использовать trust даже на многопользовательской машине, если ограничите доступ к файлу Unix-сокета сервера на уровне файловой системы. Для этого установите конфигурационные параметры unix_socket_permissions (и, возможно, unix_socket_group) как описано в Разделе 19.3. Либо вы можете установить конфигурационный параметр unix_socket_directories, чтобы разместить файл сокета в должным образом защищённом каталоге.

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

Метод аутентификации trust для подключений по TCP/IP допустим только в случае, если вы доверяете каждому пользователю компьютера, получившему разрешение на подключение к серверу строками файла pg_hba.conf, указывающими метод trust. Не стоит использовать trust для любых подключений по TCP/IP, отличных от localhost (127.0.0.1).

20.3.2. Аутентификация password

Существует несколько методов аутентификации по паролю. Они работают примерно одинаково, но различаются тем, как пароли пользователей хранятся на сервере и как пароль передаётся от клиента по каналу связи.

scram-sha-256

С методом scram-sha-256 выполняется аутентификация SCRAM-SHA-256, как описано в RFC 7677. Она производится по схеме вызов-ответ, которая предотвращает перехват паролей через недоверенные соединения и поддерживает хранение паролей на сервере в виде криптографического хеша, что считается безопасным.

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

md5

Для метода md5 реализован менее безопасный механизм вызов-ответ. Он предотвращает перехват паролей и предусматривает хранение паролей на сервере в зашифрованном виде, но не защищает в случае похищения хешей паролей с сервера. Кроме того, алгоритм хеширования MD5 в наши дни уже может не защитить от целенаправленных атак.

Метод md5 несовместим с функциональностью db_user_namespace.

Для облегчения перехода от метода md5 к более новому методу SCRAM, если в качестве метода аутентификации в pg_hba.conf указан md5, но пароль пользователя на сервере зашифрован для SCRAM (см. ниже), автоматически будет производиться аутентификация на базе SCRAM.

password

С методом password пароль передаётся в открытом виде и поэтому является уязвимым для атак с перехватом трафика. Его следует избегать всегда, если это возможно. Однако, если подключение защищено SSL, метод password может быть безопасен. (Хотя аутентификация по сертификату SSL может быть лучшим выбором когда используется SSL).

Пароли баз данных PostgreSQL отделены от паролей пользователей операционной системы. Пароли всех пользователей базы данных хранятся во внутреннем каталоге pg_authid. Управлять паролями можно, либо используя SQL-команды CREATE USER и ALTER ROLE, например, CREATE USER foo WITH PASSWORD 'secret', либо с помощью команды psql \password. Если пароль для пользователя не задан, вместо него хранится NULL, и пройти аутентификацию по паролю этот пользователь не сможет.

Доступность различных методов аутентификации по паролю зависит от того, как пароли пользователей шифруются на сервере (или, говоря точнее, хешируются). Это определяется параметром конфигурации password_encryption в момент назначения пароля. Если пароль шифруется в режиме scram-sha-256, его можно будет использовать для методов аутентификации scram-sha-256 и password (но в последнем случае он будет передаваться открытым текстом). В случае указания метода аутентификации md5 при этом произойдёт автоматический переход к использованию scram-sha-256, как сказано выше, так что этот вариант тоже будет работать. Если пароль шифруется в режиме md5, его можно будет использовать только для методов аутентификации md5 и password (и в последнем случае он так же будет передаваться открытым текстом). (Ранние версии PostgreSQL поддерживали хранение паролей на сервере в открытом виде, но теперь это невозможно.) Чтобы просмотреть хранящиеся в БД хеши паролей, обратитесь к системному каталогу pg_authid.

Для перевода существующей инсталляции с md5 на scram-sha-256, после того как все клиентские библиотеки будут обновлены до версий, поддерживающих SCRAM, задайте password_encryption = 'scram-sha-256' в postgresql.conf, добейтесь, чтобы все пользователи сменили свои пароли, а затем поменяйте указания метода аутентификации в pg_hba.conf на scram-sha-256.

20.3.3. Аутентификация GSSAPI

GSSAPI является протоколом отраслевого стандарта для безопасной авторизации, определённым в RFC 2743. PostgreSQL поддерживает GSSAPI с Kerberos аутентификацией с соответствии с RFC 1964. GSSAPI обеспечивает автоматическую аутентификацию (single sign-on), для систем, которые её поддерживают. Сама по себе аутентификация безопасна, но данные, отсылаемые в ходе подключения к базе данных, не защищены, если не используется SSL.

Поддержка GSSAPI должна быть включена при сборке PostgreSQL; за дополнительными сведениями обратитесь к Главе 16.

При работе с Kerberos GSSAPI использует стандартные учётные записи в формате servicename/hostname@realm. Сервер PostgreSQL примет любого принципала, включённого в используемый сервером файл таблицы ключей, но необходимо проявить осторожность в указании корректных деталей принципала в ходе соединения с клиентом, применяющим параметр подключения krbsrvname. (См. также Подраздел 33.1.2.) Значение имени сервиса по умолчанию postgres может быть изменено во время сборки с помощью ./configure --with-krb-srvnam=whatever. В большинстве сред изменять данный параметр не требуется. Однако некоторые реализации Kerberos могут потребовать иного имени сервиса, например, Microsoft Active Directory требует, чтобы имя сервиса было набрано заглавными буквами (POSTGRES).

hostname здесь — это полное доменное имя компьютера, где работает сервер. Областью субъекта-службы является предпочитаемая область данного компьютера.

Принципалы клиентов могут быть сопоставлены с различными именами пользователей баз данных PostgreSQL в pg_ident.conf. Например, принципалу pgusername@realm может быть сопоставлено просто pgusername. Так же возможно использовать в качестве имени роли в PostgreSQL полное имя принципала username@realm без какого-либо сопоставления.

PostgreSQL также поддерживает возможность убирать область из имени принципала. Эта возможность оставлена для обратной совместимости и использовать её крайне нежелательно, так как при этом оказывается невозможно различить разных пользователей, имеющих одинаковые имена, но приходящих из разных областей. Чтобы включить её, установите для include_realm значение 0. В простых конфигурациях с одной областью исключение области в сочетании с параметром krb_realm (который позволяет ограничить область пользователя одним значением, заданным в krb_realm parameter) будет безопасным, но менее гибким вариантом по сравнению с явным описанием сопоставлений в pg_ident.conf.

Убедитесь, что файл ключей вашего сервера доступен для чтения (и желательно недоступен для записи) учётной записи сервера PostgreSQL. (См. также Раздел 18.1.) Расположение этого файла ключей указывается параметром krb_server_keyfile. По умолчанию это /usr/local/pgsql/etc/krb5.keytab (каталог может быть другим, в зависимости от значения sysconfdir при сборке). Из соображений безопасности рекомендуется использовать отдельный файл keytab для сервера PostgreSQL, а не открывать доступ к общесистемному файлу.

Файл таблицы ключей генерируется программным обеспечением Kerberos; подробнее это описано в документации Kerberos. Следующий пример для MIT-совместимых реализаций Kerberos 5:

kadmin% ank -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

При подключении к базе данных убедитесь, что у вас есть разрешение на сопоставление принципала с именем пользователя базы данных. Например, для имени пользователя базы данных fred, принципал [email protected] сможет подключиться. Чтобы дать разрешение на подключение принципалу fred/[email protected], используйте файл сопоставления имён пользователей, как описано в Разделе 20.2.

Для метода GSSAPI доступны следующие параметры конфигурации:

include_realm

Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 20.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm. Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей PostgreSQL.

map

Разрешает сопоставление имён пользователей системы и пользователей баз данных. За подробностями обратитесь к Разделу 20.2. Для принципала GSSAPI/Kerberos, такого как [email protected] (или более редкого username/[email protected]), именем пользователя в сопоставлении будет [email protected] (или username/[email protected], соответственно), если include_realm не равно 0; в противном случае именем системного пользователя в сопоставлении будет username (или username/hostbased).

krb_realm

Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.

20.3.4. Аутентификация SSPI

SSPI — технология Windows для защищённой аутентификации с единственным входом. PostgreSQL использует SSPI в режиме negotiate, который применяет Kerberos, когда это возможно, и автоматически возвращается к NTLM в других случаях. Аутентификация SSPI возможна только когда и сервер, и клиент работают на платформе Windows или на других платформах, где доступен GSSAPI.

Если используется аутентификация Kerberos, SSPI работает так же, как GSSAPI; подробнее об этом рассказывается в Подразделе 20.3.3.

Для SSPI доступны следующие параметры конфигурации:

include_realm

Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 20.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm. Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей PostgreSQL.

compat_realm

Если равен 1, для параметра include_realm применяется имя домена, совместимое с SAM (также известное как имя NetBIOS). Это вариант по умолчанию. Если он равен 0, для имени принципала Kerberos применяется действительное имя области.

Этот параметр можно отключить, только если ваш сервер работает под именем доменного пользователя (в том числе, виртуального пользователя службы на компьютере, включённом в домен) и все клиенты, проходящие проверку подлинности через SSPI, также используют доменные учётные записи; в противном случае аутентификация не будет выполнена.

upn_username

Если этот параметр включён вместе с compat_realm, для аутентификации применяется имя Kerberos UPN. Если он отключён (по умолчанию), применяется SAM-совместимое имя пользователя. По умолчанию у новых учётных записей эти два имени совпадают.

Заметьте, что libpq использует имя, совместимое с SAM, если имя не задано явно. Если вы применяете libpq или драйвер на его базе, этот параметр следует оставить отключённым, либо явно задавать имя пользователя в строке подключения.

map

Позволяет сопоставить пользователей системы с пользователями баз данных. За подробностями обратитесь к Разделу 20.2. Для принципала SSPI/Kerberos, такого как [email protected] (или более редкого username/[email protected]), именем пользователя в сопоставлении будет [email protected] (или username/[email protected], соответственно), если include_realm не равно 0; в противном случае именем системного пользователя в сопоставлении будет username (или username/hostbased).

krb_realm

Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.

20.3.5. Аутентификация ident

Метод аутентификации ident работает, получая имя пользователя операционной системы клиента от сервера Ident и используя его в качестве разрешённого имени пользователя базы данных (с возможным сопоставлением имён пользователя). Способ доступен только для подключений по TCP/IP.

Примечание

Когда для локального подключения (не TCP/IP) указан ident, вместо него используется метод аутентификации peer (см. Подраздел 20.3.6).

Для метода ident доступны следующие параметры конфигурации:

map

Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 20.2.

Протокол «Identification» (Ident) описан в RFC 1413. Практически каждая Unix-подобная операционная система поставляется с сервером Ident, по умолчанию слушающим TCP-порт 113. Базовая функция этого сервера — отвечать на вопросы, вроде «Какой пользователь инициировал подключение, которое идет через твой порт X и подключается к моему порту Y?». Поскольку после установления физического подключения PostgreSQL знает и X, и Y, он может опрашивать сервер Ident на компьютере клиента и теоретически может определять пользователя операционной системы при каждом подключении.

Недостатком этой процедуры является то, что она зависит от интеграции с клиентом: если клиентская машина не вызывает доверия или скомпрометирована, злоумышленник может запустить любую программу на порту 113 и вернуть любое имя пользователя на свой выбор. Поэтому этот метод аутентификации подходит только для закрытых сетей, где каждая клиентская машина находится под жёстким контролем и где администраторы операционных систем и баз данных работают в тесном контакте. Другими словами, вы должны доверять машине, на которой работает сервер Ident. Помните предупреждение:

 

Протокол Ident не предназначен для использования в качестве протокола авторизации и контроля доступа.

 
 —RFC 1413

У некоторых серверов Ident есть нестандартная возможность, позволяющая зашифровать возвращаемое имя пользователя, используя ключ, который известен только администратору исходного компьютера. Эту возможность нельзя использовать с PostgreSQL, поскольку PostgreSQL не сможет расшифровать возвращаемую строку и получить фактическое имя пользователя.

20.3.6. Аутентификация peer

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

Для метода peer доступны следующие параметры конфигурации:

map

Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 20.2.

Аутентификация peer доступна только в операционных системах, поддерживающих функцию getpeereid(), параметр сокета SO_PEERCRED или подобные механизмы. В настоящее время это Linux, большая часть разновидностей BSD, включая macOS, и Solaris.

20.3.7. Аутентификация LDAP

Данный метод аутентификации работает сходным с методом password образом, за исключением того, что он использует LDAP как метод подтверждения пароля. LDAP используется только для подтверждения пары «имя пользователя/пароль». Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован LDAP.

Аутентификация LDAP может работать в двух режимах. Первый режим называется простое связывание. В ходе аутентификации сервер связывается с характерным именем, составленным следующим образом: prefix username suffix. Обычно, параметр prefix используется для указания cn= или DOMAIN\ в среде Active Directory. suffix используется для указания оставшейся части DN или в среде, отличной от Active Directory.

Во втором режиме, который мы называем поиск+связывание, сервер сначала связывается с каталогом LDAP с предопределённым именем пользователя и паролем, указанным в ldapbinddn и ldapbindpasswd, и выполняет поиск пользователя, пытающегося подключиться к базе данных. Если имя пользователя и пароль не определены, сервер пытается связаться с каталогом анонимно. Поиск выполняется в поддереве ldapbasedn, при этом проверятся точное соответствие имени пользователя атрибуту ldapsearchattribute. Как только при поиске находится пользователь, сервер отключается и заново связывается с каталогом уже как этот пользователь, с паролем, переданным клиентом, чтобы удостовериться, что учётная запись корректна. Этот же режим используется в схемах LDAP-аутентификации в другом программном обеспечении, например, в pam_ldap и mod_authnz_ldap в Apache. Данный вариант даёт больше гибкости в выборе расположения объектов пользователей, но при этом требует дважды подключаться к серверу LDAP.

Следующие параметры конфигурации доступны при аутентификации в обоих режимах:

PostgreSQL 9.2 Начало! / Хабр

Мне хотелось создать прекрасный объемлющий мануал Getting Start без всякой воды, но включающий основные плюшки для начинающих по системе PostgreSQL в Linux.

PostgreSQL является объектно-реляционной системой управления базами данных (ОРСУБД) на основе POSTGRES, версия 4.2, разработанной в Университете Калифорнии в Беркли департаменте компьютерных наук.

PostgreSQL является open source потомком оригинального кода Berkeley. Он поддерживает большую часть стандарта SQL и предлагает множество современных функций:

Кроме того, PostgreSQL может быть расширен пользователем во многих отношениях, например, путем добавления новых

  • типов данных

  • функций

  • операторов

  • агрегатных функций

  • индекс методов

  • процедурных языков

Сборка и установка

Как и все любители мейнстрима PostgreSQL мы будем конечно же собирать, а не скачивать готовые пакеты (в репозитариях Debian, например, нет последней версии). Вот здесь лежит множество версий, скачивать конечно же лучше всего последнюю. На момент написания поста это версия 9.2.2

wget http://ftp.postgresql.org/pub/source/v9.2.2/postgresql-9.2.2.tar.gz
tar xzf postgresql-9.2.2.tar.gz

Теперь у нас есть директория с исходниками сей прекрасной базы данных.
По умолчанию файлы базы будут установлены в директорию /usr/local/pgsql, но эту директорию можно изменить задав

--prefix=/path/to/pgsql

перед командой ./configure
Перед сборкой можно указать компилятор С++

export CC=gcc

PostgeSQL может использовать readline библиотеку, если у вас её нет и нет желания её ставить просто укажите опцию

--without-readline

Надеюсь у всех есть Autotools? Тогда вперед к сборке:

cd postgresql-9.2.2
./configure --without-readline
sudo make install clean

Все господа! Поздравляю!

Настройка

Нам необходимо указать хранилище данных наших баз данных (кластер) и запустить её.

Есть один нюанс — владельцем директории данных и пользователь, который может запускать базу должен быть не root. Это сделано в целях безопасности системы. Поэтому создадим специального пользователя

sudo useradd postgres -p postgres -U -m

И далее все понятно

sudo chown -R postgres:postgres /usr/local/pgsql

Важный процесс. Мы должны инициализировать кластер баз дынных. Сделать мы должны это от имени пользователя postgres

initdb -D /usr/local/pgsql/data

Теперь нужно добавить запуск PostgreSQL в автостарт. Для этого существует уже готовый скрипт и лежит он в postgresql-9.2.2/contrib/start-scripts/linux
Этот файл можно открыть и обратить внимание на следующие переменные:

  • prefix — это место куда мы ставили PostgreSQL и задавали в ./configure

  • PGDATA — это то, где хранится кластер баз данных и куда должен иметь доступ наш пользователь postgres

  • PGUSER — это тот самый пользователь, от лица которого будет все работать

Если все стоит верно, то добвляем наш скрипт в init.d

sudo cp ./postgresql-9.2.2/contrib/start-scripts/linux /etc/init.d/postgres
sudo update-rc.d postgres defaults

Перезапускам систему, чтобы проверить что наш скрипт работает.
Вводим

/usr/local/pgsql/bin/psql -U postgres

И если появится окно работы с базой, то настройка прошла успешно! Поздравляю!
По умолчанию создается база данных с именем postgres

Теперь важно поговорить о методах авторизации.

В /usr/local/pgsql/data/pg_hba.conf как раз есть необходимые для этого настройка

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     trust
host    all             all             127.0.0.1/32            trust
host    all             all             ::1/128                 trust

Первая строка отвечает за локальное соединение, вторая — за соединение про протоколу IPv4, а третья по протоколу IPv6.
Самый последний параметр — это как раз таки метод авторизации. Его и рассмотрим (только основные)

  • trust — доступ к базе может получить кто угодно под любым именем, имеющий с ней соединение.

  • reject — отклонить безоговорочно! Это подходит для фильтрации определенных IP адресов

  • password — требует обязательного ввода пароля. Не подходит для локальных пользователей, только пользователи созданные командой CREATE USER

  • ident — позволяет только пользователем зарегистрированным в файле /usr/local/pgsql/data/pg_ident.conf устанавливать соединение с базой.

Вкратце расскажу об основных утилитах, которые пригодятся в работе.

Утилиты для работы с базой

pg_config

Возвращает информацию о текущей установленной версии PostgreSQL.

initdb

Инициализирует новое хранилище данных (кластер баз данных). Кластер представляет собой совокупность баз данных управляемых одним экземпляром севера. initdb должен быть запущен от имени будущего владельца сервера (как указано выше от имени postgres).

pg_ctl

Управляет процессом работы сервера PostgreSQL. Позволяет запускать, выполнять перезапуск, останавливать работу сервера, указать лог файл и другое.

psql

Клиент для работы с базой дынных. Позволяет выполнять SQL операции.

createdb

Создает новую базу данных. По умолчанию, база данных создается от имени пользователя, который запускает команду. Однако, чтобы задать другого — необходимо использовать опцию -O (если у пользователя есть необходимые привилегии для этого). По сути — это обертка SQL команды CREATE DATABASE.

dropdb

Удаляет базу данных. Является оберткой SQL команды DROP DATABASE.

createuser

Добавляет нового пользователя базы дынных. Является оберткой SQL команды CREATE ROLE.

dropuser

Удаляет пользователя базы данных. Является оберткой SQL команды DROP ROLE.

createlang

Добавляет новый язык программирования в базу PostgreSQL. Является оберткой SQL команды CREATE LANGUAGE.

droplang

Удаляет язык программирования. Является оберткой SQL команды DROP LANGUAGE.

pg_dump

Создает бэкап (дамп) базы данных в файл.

pg_restore

Восстанавливает бэкап (дамп) базы данных из файла.

pg_dumpall

Создает бэкап (дамп) всего кластера в файл.

reindexdb

Производит переиндексацию базы данных. Является оберткой SQL команды REINDEX.

clusterdb

Производит перекластеризацию таблиц в базе данных. Является оберткой SQL команды CLUSTER.

vacuumdb

Сборщик мусора и оптимизатор базы данных. Является оберткой SQL команды VACUUM.

Менеджеры по работе с базой

Что касается менеджера по работа с базой, то есть php менеджер — это phpPgAdmin и GUI менеджер pgAdmin. Должен заметить, что они оба плохо поддерживают последнюю версию PostgreSQL.

P.S Если что-то забыл, скажите — добавлю.

PostgreSQL : Документация: 9.6: 20.3. Методы аутентификации : Компания Postgres Professional

20.3. Методы аутентификации

Следующие подразделы содержат более детальную информацию о методах аутентификации.

20.3.1. Аутентификация trust

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

Аутентификация trust очень удобна для локальных подключений на однопользовательской рабочей станции. Но сам по себе этот метод обычно не подходит для машин с несколькими пользователями. Однако вы можете использовать trust даже на многопользовательской машине, если ограничите доступ к файлу Unix-сокета сервера на уровне файловой системы. Для этого установите конфигурационные параметры unix_socket_permissions (и, возможно, unix_socket_group) как описано в Разделе 19.3. Либо вы можете установить конфигурационный параметр unix_socket_directories, чтобы разместить файл сокета в должным образом защищённом каталоге.

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

Метод аутентификации trust для подключений по TCP/IP допустим только в случае, если вы доверяете каждому пользователю компьютера, получившему разрешение на подключение к серверу строками файла pg_hba.conf, указывающими метод trust. Не стоит использовать trust для любых подключений по TCP/IP, отличных от localhost (127.0.0.1).

20.3.2. Аутентификация password

Методы аутентификации с помощью пароля — md5 и password. Эти методы действуют похожим образом; отличие состоит только в том, как передаётся пароль по каналу связи, а именно: в виде хеша MD5, или открытым текстом, соответственно.

Если вас беспокоит возможность перехвата трафика, предпочтительнее использовать метод md5. Простого метода password следует избегать всегда, если возможно. Однако, md5 не может быть использован с параметром db_user_namespace. Если подключение зашифровано по SSL, тогда password тоже может быть использован без опасений (хотя аутентификация через SSL сертификат будет наилучшим выбором для тех, кто зависит от использования SSL).

База данных паролей PostgreSQL отделена от паролей пользователей операционной системы. Пароль для каждого пользователя базы данных хранится в системном каталоге pg_authid. Работать с паролями можно через команды SQL CREATE USER и ALTER ROLE, например, CREATE USER foo WITH PASSWORD 'secret'. Если для пользователя не было установлено пароля, пароль сохраняется как null, и аутентификация через пароль для данного пользователя будет невозможна.

20.3.3. Аутентификация GSSAPI

GSSAPI является протоколом отраслевого стандарта для безопасной авторизации, определённым в RFC 2743. PostgreSQL поддерживает GSSAPI с Kerberos аутентификацией с соответствии с RFC 1964. GSSAPI обеспечивает автоматическую аутентификацию (single sign-on), для систем, которые её поддерживают. Сама по себе аутентификация безопасна, но данные, отсылаемые в ходе подключения к базе данных, не защищены, если не используется SSL.

Поддержка GSSAPI должна быть включена при сборке PostgreSQL; за дополнительными сведениями обратитесь к Главе 16.

При работе с Kerberos GSSAPI использует стандартные учётные записи в формате servicename/hostname@realm. Сервер PostgreSQL примет любого принципала, включённого в используемый сервером файл таблицы ключей, но необходимо проявить осторожность в указании корректных деталей принципала в ходе соединения с клиентом, применяющим параметр подключения krbsrvname. (См. также Подраздел 32.1.2.) Значение имени сервиса по умолчанию postgres может быть изменено во время сборки с помощью ./configure --with-krb-srvnam=whatever. В большинстве сред изменять данный параметр не требуется. Однако некоторые реализации Kerberos могут потребовать иного имени сервиса, например, Microsoft Active Directory требует, чтобы имя сервиса было набрано заглавными буквами (POSTGRES).

hostname здесь — это полное доменное имя компьютера, где работает сервер. Областью субъекта-службы является предпочитаемая область данного компьютера.

Принципалы клиентов могут быть сопоставлены с различными именами пользователей баз данных PostgreSQL в pg_ident.conf. Например, принципалу pgusername@realm может быть сопоставлено просто pgusername. Так же возможно использовать в качестве имени роли в PostgreSQL полное имя принципала username@realm без какого-либо сопоставления.

PostgreSQL также поддерживает возможность убирать область из имени принципала. Эта возможность оставлена для обратной совместимости и использовать её крайне нежелательно, так как при этом оказывается невозможно различить разных пользователей, имеющих одинаковые имена, но приходящих из разных областей. Чтобы включить её, установите для include_realm значение 0. В простых конфигурациях с одной областью исключение области в сочетании с параметром krb_realm (который позволяет ограничить область пользователя одним значением, заданным в krb_realm parameter) будет безопасным, но менее гибким вариантом по сравнению с явным описанием сопоставлений в pg_ident.conf.

Убедитесь, что файл ключей вашего сервера доступен для чтения (и желательно недоступен для записи) учётной записи сервера PostgreSQL. (См. также Раздел 18.1.) Расположение этого файла ключей указывается параметром krb_server_keyfile. По умолчанию это /usr/local/pgsql/etc/krb5.keytab (каталог может быть другим, в зависимости от значения sysconfdir при сборке). Из соображений безопасности рекомендуется использовать отдельный файл keytab для сервера PostgreSQL, а не открывать доступ к общесистемному файлу.

Файл таблицы ключей генерируется программным обеспечением Kerberos; подробнее это описано в документации Kerberos. Следующий пример для MIT-совместимых реализаций Kerberos 5:

kadmin% ank -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

При подключении к базе данных убедитесь, что у вас есть разрешение на сопоставление принципала с именем пользователя базы данных. Например, для имени пользователя базы данных fred, принципал [email protected] сможет подключиться. Чтобы дать разрешение на подключение принципалу fred/[email protected], используйте файл сопоставления имён пользователей, как описано в Разделе 20.2.

Для метода GSSAPI доступны следующие параметры конфигурации:

include_realm

Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 20.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm. Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей PostgreSQL.

map

Разрешает сопоставление имён пользователей системы и пользователей баз данных. За подробностями обратитесь к Разделу 20.2. Для принципала GSSAPI/Kerberos, такого как [email protected] (или более редкого username/[email protected]), именем пользователя в сопоставлении будет [email protected] (или username/[email protected], соответственно), если include_realm не равно 0; в противном случае именем системного пользователя в сопоставлении будет username (или username/hostbased).

krb_realm

Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.

20.3.4. Аутентификация SSPI

SSPI — технология Windows для защищённой аутентификации с единственным входом. PostgreSQL использует SSPI в режиме negotiate, который применяет Kerberos, когда это возможно, и автоматически возвращается к NTLM в других случаях. Аутентификация SSPI возможна только когда и сервер, и клиент работают на платформе Windows или на других платформах, где доступен GSSAPI.

Если используется аутентификация Kerberos, SSPI работает так же, как GSSAPI; подробнее об этом рассказывается в Подразделе 20.3.3.

Для SSPI доступны следующие параметры конфигурации:

include_realm

Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 20.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm. Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей PostgreSQL.

compat_realm

Если равен 1, для параметра include_realm применяется имя домена, совместимое с SAM (также известное как имя NetBIOS). Это вариант по умолчанию. Если он равен 0, для имени принципала Kerberos применяется действительное имя области.

Этот параметр можно отключить, только если ваш сервер работает под именем доменного пользователя (в том числе, виртуального пользователя службы на компьютере, включённом в домен) и все клиенты, проходящие проверку подлинности через SSPI, также используют доменные учётные записи; в противном случае аутентификация не будет выполнена.

upn_username

Если этот параметр включён вместе с compat_realm, для аутентификации применяется имя Kerberos UPN. Если он отключён (по умолчанию), применяется SAM-совместимое имя пользователя. По умолчанию у новых учётных записей эти два имени совпадают.

Заметьте, что libpq использует имя, совместимое с SAM, если имя не задано явно. Если вы применяете libpq или драйвер на его базе, этот параметр следует оставить отключённым, либо явно задавать имя пользователя в строке подключения.

map

Позволяет сопоставить пользователей системы с пользователями баз данных. За подробностями обратитесь к Разделу 20.2. Для принципала SSPI/Kerberos, такого как [email protected] (или более редкого username/[email protected]), именем пользователя в сопоставлении будет [email protected] (или username/[email protected], соответственно), если include_realm не равно 0; в противном случае именем системного пользователя в сопоставлении будет username (или username/hostbased).

krb_realm

Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.

20.3.5. Аутентификация ident

Метод аутентификации ident работает, получая имя пользователя операционной системы клиента от сервера Ident и используя его в качестве разрешённого имени пользователя базы данных (с возможным сопоставлением имён пользователя). Способ доступен только для подключений по TCP/IP.

Примечание

Когда для локального подключения (не TCP/IP) указан ident, вместо него используется метод аутентификации peer (см. Подраздел 20.3.6).

Для метода ident доступны следующие параметры конфигурации:

map

Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 20.2.

Протокол «Identification» (Ident) описан в RFC 1413. Практически каждая Unix-подобная операционная система поставляется с сервером Ident, по умолчанию слушающим TCP-порт 113. Базовая функция этого сервера — отвечать на вопросы, вроде «Какой пользователь инициировал подключение, которое идет через твой порт X и подключается к моему порту Y?». Поскольку после установления физического подключения PostgreSQL знает и X, и Y, он может опрашивать сервер Ident на компьютере клиента и теоретически может определять пользователя операционной системы при каждом подключении.

Недостатком этой процедуры является то, что она зависит от интеграции с клиентом: если клиентская машина не вызывает доверия или скомпрометирована, злоумышленник может запустить любую программу на порту 113 и вернуть любое имя пользователя на свой выбор. Поэтому этот метод аутентификации подходит только для закрытых сетей, где каждая клиентская машина находится под жёстким контролем и где администраторы операционных систем и баз данных работают в тесном контакте. Другими словами, вы должны доверять машине, на которой работает сервер Ident. Помните предупреждение:

 

Протокол Ident не предназначен для использования в качестве протокола авторизации и контроля доступа.

 
 —RFC 1413

У некоторых серверов Ident есть нестандартная возможность, позволяющая зашифровать возвращаемое имя пользователя, используя ключ, который известен только администратору исходного компьютера. Эту возможность нельзя использовать с PostgreSQL, поскольку PostgreSQL не сможет расшифровать возвращаемую строку и получить фактическое имя пользователя.

20.3.6. Аутентификация peer

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

Для метода peer доступны следующие параметры конфигурации:

map

Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 20.2.

Аутентификация peer доступна только на операционных системах, поддерживающих функцию getpeereid(), параметр сокета SO_PEERCRED или сходные механизмы. В настоящее время это Linux, большая часть разновидностей BSD, включая OS X, и Solaris.

20.3.7. Аутентификация LDAP

Данный метод аутентификации работает сходным с методом password образом, за исключением того, что он использует LDAP как метод подтверждения пароля. LDAP используется только для подтверждения пары «имя пользователя/пароль». Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован LDAP.

Аутентификация LDAP может работать в двух режимах. Первый режим называется простое связывание. В ходе аутентификации сервер связывается с характерным именем, составленным следующим образом: prefix username suffix. Обычно, параметр prefix используется для указания cn= или DOMAIN\ в среде Active Directory. suffix используется для указания оставшейся части DN или в среде, отличной от Active Directory.

Во втором режиме, который мы называем поиск+связывание, сервер сначала связывается с каталогом LDAP с предопределённым именем пользователя и паролем, указанным в ldapbinddn и ldapbindpasswd, и выполняет поиск пользователя, пытающегося подключиться к базе данных. Если имя пользователя и пароль не определены, сервер пытается связаться с каталогом анонимно. Поиск выполняется в поддереве ldapbasedn, при этом проверятся точное соответствие имени пользователя атрибуту ldapsearchattribute. Как только при поиске находится пользователь, сервер отключается и заново связывается с каталогом уже как этот пользователь, с паролем, переданным клиентом, чтобы удостовериться, что учётная запись корректна. Этот же режим используется в схемах LDAP-аутентификации в другом программном обеспечении, например, в pam_ldap и mod_authnz_ldap в Apache. Данный вариант даёт больше гибкости в выборе расположения объектов пользователей, но при этом требует дважды подключаться к серверу LDAP.

Следующие параметры конфигурации доступны при аутентификации в обоих режимах:

ldapserver

Имена и IP-адреса LDAP-серверов для связи. Можно указать несколько серверов, разделяя их пробелами.

ldapport

Номер порта для связи с LDAP-сервером. Если порт не указан, используется установленный по умолчанию порт библиотеки LDAP.

ldaptls

Равен 1 для установки соединения между PostgreSQL и LDAP-сервером с использованием TLS-шифрования. Имейте в виду, что так шифруется только обмен данными с LDAP-сервером, а клиентское подключение остаётся незашифрованным, если только не применяется SSL.

postgresql — пользователь и пароль postgres по умолчанию

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

Загрузка…

.

Какой пароль по умолчанию для PostgreSQL?

Время чтения: <1 минуты

При первом подключении к PostgreSQL в Linux у многих администраторов возникают вопросы, особенно если они из мира MySQL. По умолчанию, когда установлен PostgreSQL, также добавляется пользователь postgres .

Если запустить команду:

кот / etc / passwd

… вы увидите пользователя postgres .

postgres: x: 26: 26: Сервер PostgreSQL: / var / lib / pgsql: / bin / bash

Первый вопрос, который задают многие: «Какой пароль по умолчанию для пользователя postgres?» Ответ прост … пароля по умолчанию нет.По умолчанию для PostgreSQL установлен режим аутентификации , идентификатор .

кот /var/lib/pgsql/9.3/data/pg_hba.conf

… вы увидите, что режим аутентификации — , идентификатор .

# локальные подключения IPv4:
хост все все 127.0.0.1/32 идентификатор
# локальные подключения IPv6:
хост все все :: 1/128 идентификатор

Что такое метод аутентификации с помощью идентификатора? Что ж, он работает, беря имя пользователя ОС, под которым вы работаете, и сравнивая его с разрешенными именами пользователей базы данных.Существует необязательное сопоставление имени пользователя.

Это означает, что для подключения к PostgreSQL вы должны войти в систему как правильный пользователь ОС. В этом случае мы вошли на сервер как root . Когда мы пытаемся подключиться к PostgreSQL:

psql

… получаем ошибку:

psql: FATAL: роль «корень» не существует

Однако, если мы станем пользователем PostgreSQL по умолчанию, postgres :

su - postgres

… затем попытайтесь подключиться к PostgreSQL:

psql

… Я получаю правильный, обоснованный ответ!

psql (9.3.9)
Введите "help" для получения справки.

postgres = #

Ваш облачный VPS замедляет работу вашего экземпляра PostgreSQL? Выделенные серверы Liquid Web — это решение. Сервер Liquid Web превосходит конкурентов по производительности и поддержке. Узнайте, как наш VPS-сервер или выделенные серверы могут резко повысить производительность вашего сайта.

.База данных

— как создать пользователя для базы данных в postgresql?

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

Загрузка…

.База данных

— Как добавить пользователя в PostgreSQL в Windows?

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

.

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *