Какие базы данных необходимо синхронизировать? #

Запрос databases_query возвращает плоский список баз данных для управления. В результате выполнения запроса databases_query в список должна попасть база данных по умолчанию, определённая в PGDATABASE. При удалении ролей ldap2pg циклично просматривает список баз данных, чтобы переназначить объекты и отозвать права, предоставленные ролям, которые будут удалены. Список баз данных также позволяет сузить рамки проверки предоставленных прав. ldap2pg будет отзывать предоставленные права только в базах данных из списка. За подробностями обратитесь к Подразделу «Раздел postgres».

postgres:
  databases_query: |
    SELECT datname
    FROM pg_catalog.pg_database
    WHERE datallowconn IS TRUE;

Синхронизация подмножества ролей #

По умолчанию ldap2pg управляет всеми ролями Postgres Pro, к которым имеет доступ, кроме ролей, добавленных в чёрный список по умолчанию. Чтобы ldap2pg синхронизировало только подмножество ролей, необходимо настроить выборку внутри postgres:managed_roles_query. Пример запроса ниже позволяет исключить суперпользователей из объектов для синхронизации.

postgres:
  managed_roles_query: |
    SELECT 'public'
    UNION
    SELECT rolname
    FROM pg_catalog.pg_roles
    WHERE rolsuper IS FALSE
    ORDER BY 1;

ldap2pg будет выполнять операции по удалению, отзыву и предоставлению прав только для тех ролей, которые будут получены в результате этого запроса.

Часто подобный запрос ограничивает выборку одной группой, например, ldap_roles. Таким образом ldap2pg работает только с подмножеством ролей в кластере.

Роли public нет в системном каталоге. Поэтому чтобы ldap2pg управляло правами public, необходимо явно включить роль public в список управляемых ролей. Это настройки по умолчанию. Но даже если роль public управляемая, ldap2pg не будет удалять или менять её, если её нет в каталоге.

Чтобы полностью исключить некоторые роли из выборки, можно использовать roles_blacklist_query.

postgres:
  roles_blacklist_query: [postgres, pg_*]  # Это значение по умолчанию.

Проверка схем #

Для управления правами, которые действуют на уровне схем, ldap2pg необходимо знать, какими схемами оно может управлять в рамках каждой базы данных. Для этого используется запрос schemas_query.

Настройка прав по умолчанию для роли владельца #

Чтобы настроить права по умолчанию, ссылаясь на право, используйте ключевое слово default:

privileges:
  reading:
  - default: global
    type: SELECT
    on: TABLES

Затем предоставьте право, используя правило предоставления прав:

rules:
- grant:
  - privilege: reading
    role: readers
    schema: public
    owner: ownerrole

В качестве владельца можно использовать роль __auto__. Для каждой схемы ldap2pg настроит все управляемые роли, которые имеют право CREATE в схеме.

rules:
- grant:
  - privilege: reading
    role: readers
    schema: public
    owner __auto__

ldap2pg настраивает права по умолчанию в последнюю очередь после всех действующих прав. Таким образом право CREATE в схеме предоставляется до того, как ldap2pg проверит роли создателей в схемах.

Статические запросы #

Все запросы можно заменить статическим списком в формате YAML. Этот список будет использоваться, как будто он получен от Postgres Pro. Это очень удобно, если нужно заморозить какое-то значение, например, указание на базы данных или схемы.

postgres:
  databases_query: [postgres]
  schemas_query: [public]

Запуск без прав суперпользователя #

Расширение ldap2pg предназначено для работы от имени не суперпользователя. Пользователь, который будет выполнять синхронизацию, должен иметь атрибут CREATEROLE, чтобы управлять другими ролями не суперпользователя. Атрибут CREATEDB позволяют такому пользователю управлять владельцами баз данных.

Чтобы пользователь ldap2pg мог правильно управлять группами, параметру createrole_self_grant должно быть задано значение inherit,set.

CREATE ROLE ldap2pg LOGIN CREATEDB CREATEROLE;
ALTER ROLE ldap2pg SET createrole_self_grant TO 'inherit,set;

Запуск без прав суперпользователя до версии PostgreSQL 16 реализован некорректно. В таких случаях в целях безопасности рекомендуется запускать ldap2pg с правами суперпользователя.

Игнорирование ролей #

ldap2pg полностью игнорирует роли, которые соответствуют одному из глобальных шаблонов, определённых в roles_blacklist_query:

    postgres:
      # Это значение по умолчанию.
      roles_blacklist_query: [postgres, pg_*]
    

Черный список ролей также влияет на предоставление прав. ldap2pg не будет выполнять команды grant и revoke для роли, которая соответствует одному из элементов черного списка.

ldap2pg помещает в чёрный список своего пользователя.

Членство #

ldap2pg управляет родительскими ролями. К ним ldap2pg применяет ограничение roles_blacklist_query. Однако ldap2pg может предоставлять права неуправляемым родительским ролям. Таким образом можно создавать группу вручную и управлять её членами с помощью ldap2pg.

Конфигурация доступа к каталогу #

ldap2pg читает конфигурацию каталога из файла ldaprc и через переменные окружения LDAP*. Доступные параметры LDAP:

За подробностями о значении и формате каждого параметра обращайтесь к странице man ldap.conf(5).

Внедрение атрибутов LDAP #

В ряд параметров можно внедрить атрибуты LDAP в фигурных скобках. Для этого заключите имя атрибута в фигурные скобки. Например, {cn} или {sAMAccountName}. ldap2pg расширяется до всех значений атрибута для каждой записи, найденной в результате поиска.

Если в параметре несколько атрибутов LDAP, ldap2pg получает все комбинации атрибутов для каждой записи.

Рассмотрим следующие записи LDAP:

dn: uid=dimitri,cn=Users,dc=bridoulou,dc=fr
objectClass: inetOrgPerson
uid: dimitri
sn: Dimitri
cn: dimitri
mail: dimitri@bridoulou.fr
company: external
dn: cn=domitille,cn=Users,dc=bridoulou,dc=fr
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: domitille
sn: Domitille
company: acme
company: external

Формат {company}_{cn} с приведёнными выше записями LDAP сгенерирует следующие строки:

Псевдоатрибут dn всегда доступен и ссылается на уникальное имя (DN) исходной записи LDAP.

- ldapsearch: ...
  role: "{cn.lower()}"

Основы #

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

ldap2pg оперирует следующими основными объектами при управлении правами:

В файле ldap2pg.yml содержатся профили прав и правила назначения прав. ldap2pg синхронизирует ACL по одному, базу данных за базой данных. В последнюю очередь ldap2pg синхронизирует права по умолчанию.

По умолчанию ldap2pg не управляет правами. Чтобы включить управление правами, сначала необходимо определить хотя бы один активный профиль в разделе privileges. Проще всего переиспользовать в активном пользовательском профиле встроенные профили прав, входящие в дистрибутив ldap2pg.

Определение профилей прав #

Профиль прав — список ссылок на типы прав, связанные с ACL, или другие профили. ldap2pg устанавливает несколько предопределённых ACL, таких как DATABASE, LANGUAGE и т. д. Тип права может иметь значение USAGE, CONNECT и т.д, в соответствии с описанием в Разделе 5.8. За подробностями о формате профиля прав обратитесь к документации, посвященной YAML-разделу privileges.

ldap2pg загружает ACL, на который даётся ссылка, через проверку в кластере Postgres Pro с помощью детально прописанных запросов. ldap2pg проверяет только ACL, на которые даётся ссылка хотя бы в одном профиле. Найденные в кластере назначения прав отзываются, если иное явно не прописано в правиле grant.

Расширенная проверка экземпляра #

При управлении ролями ldap2pg проводит более глубокую проверку экземпляра Postgres Pro. После синхронизации ролей и перед синхронизацией прав ldap2pg проверяет схемы. После синхронизации прав и перед синхронизацией прав по умолчанию ldap2pg проверяет владельца объектов. Владелец объекта — это роль, у которой есть право CREATE в схеме.

Назначение профиля прав #

Проверка миллионов прав отнимает у экземпляра PostgreSQL много ресурсов. Известно, что процесс отзыва прав в PostgreSQL медленный. Лучше всего назначать права группе ролей, чтобы пользователи наследовали права. ldap2pg позволяет определять статические группы в YAML и наследовать их при создании роли из каталога.

Используйте grant rule, чтобы назначить профиль прав одной или нескольким ролям. При назначении прав необходимо определить правообладателя. Назначение можно ограничить одной или несколькими базами данных, а также одной или несколькими схемами. Если профиль прав включает права по умолчанию, можно определить владельцев, которым будут назначены права по умолчанию.

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

Пример #

В примере ниже определён профиль с тремя правами. В rules определяются три группы ролей, и им назначается соответствующий профиль прав:

privileges:
  reading:
  - __connect__
  - __usage_on_schemas__
  - __select_on_tables__
  writing:
  - reading  # включает права чтения
  - __insert_on_tables__
  - __update_on_tables__
  owning:
  - writing
  - __create_on_schemas__
  - __truncate_on_tables__
rules:
- role:
  - names:
    - readers
    - writers
    - owners
    options: NOLOGIN
- grant:
  - privilege: reading
    role: readers
  - privilege: writing
    role: writers
  - privilege: owning
    role: owners

Ещё один способ включить права чтения данных в права записи — сделать так, чтобы группа ролей с правами записи (writers) наследовала группу ролей с правами чтения (readers).

Управление правами public #

В Postgres Pro есть псевдороль с именем public. Это универсальная роль, которая включает всех пользователей. Все роли в Postgres Pro неявно наследуют от роли public. При назначении права роли public это право также назначается всем существующим ролям и ролям, которые будут созданы в дальнейшем.

У Postgres Pro также есть схема public. Схема public — это существующая схема, которая доступна во всех базах данных.

В Postgres Pro есть несколько встроенных прав для роли public и особенно для схемы public. Например, у public есть право CONNECT ко всем базам данных по умолчанию. Это означает, что для конфигурации доступа к базам данных можно использовать только файл pg_hba.conf, что требует прав администратора для доступа к кластеру и вызова функции pg_reload_conf().

По умолчанию ldap2pg включает роль public в список управляемых ролей. Предопределённый ACL знает, как проверять встроенные права, назначенные роли public. Если роль public нужно сохранить, исключите роль public из managed_roles_query.

Управление правами по умолчанию #

Если права SELECT предоставляются роли на все таблицы в схеме, права не будут распространяться на новые таблицы, созданные после предоставления прав. Вместо того, чтобы после создания каждого нового объекта выполнять ldap2pg заново, в Postgres Pro предусмотрено определение прав по умолчанию для объектов, которые будут созданы в дальнейшем.

Postgres Pro привязывает права по умолчанию к роли создателя (creator). Когда пользователь с этой ролью создаёт объект, Postgres Pro предоставляет соответствующие права по умолчанию новому объекту. Например, благодаря команде ALTER DEFAULT PRIVILEGES FOR ROLE bob GRANT SELECT ON TABLES TO alice; в каждой новой таблице, создаваемой пользователем с ролью bob у пользователя с ролью alice будет право SELECT:

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

ldap2pg проверяет создателей в Postgres Pro, по схемам, не в каталоге LDAP. Создатель — это роль с атрибутом LOGIN и правом CREATE в схеме. Вручную для любой управляемой роли можно назначить целевого владельца предоставляемых прав.

В ldap2pg нельзя настроить права на схемы с атрибутом __all__. Вместо этого используйте список ACL GLOBAL DEFAULT. Если предоставление и отзыв прав по умолчанию необходимо ограничить схемой, используйте список ACL SCHEMA DEFAULT.

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

privileges:
  reading:
  - type: SELECT
    on: SCHEMA DEFAULT
    object: TABLES
  owning:
  - type: CREATE
    on: SCHEMAS

rules:
- roles:
    names:
    - alice
    - bob
    options: LOGIN
- grant:
    privilege: owning
    role: alice
- grant:
    privilege: reading
    role: bob

В Postgres Pro есть жёстко заданные глобальные права по умолчанию. Если у роли не настроены глобальные права по умолчанию, Postgres Pro подразумевает некоторые права. По умолчанию Postgres Pro предоставляет права только роли владельца (owner). Их можно посмотреть при изменении прав по умолчанию. Postgres Pro скопирует жёстко заданные значения вместе с предоставленными вами правами.

Если явно повторно не предоставить жёстко заданные права в файле ldap2pg.yml, ldap2pg отзовет их. Обратите внимание, что владельцу таблицы не нужно предоставлять право SELECT для принадлежащих ему таблиц. Поэтому в жёстко заданных правах по умолчанию нет необходимости. Так что можно разрешить ldap2pg убрать эти ненужные права по умолчанию.

Использование предопределённых профилей прав #

Профиль прав — список ссылок на тип права в ACL. В ldap2pg ACL — набор запросов для проверки, предоставления и отзыва прав на классы объектов. Запрос на проверку расширяет тип aclitem Postgres Pro для отображения всех предоставленных прав из системного каталога. Профиль прав может включать другой профиль.

Имя встроенного профиля обрамляется двойным нижним подчёркиванием (__). ldap2pg отключает профиль прав, который начинается с _. Чтобы включить такие профили, необходимо добавить встроенный профиль прав в другой профиль. Если два профиля ссылаются на одно и то же право, ldap2pg проверит его один раз.

privileges:
  ro:
  - __connect__
  - __usage_on_schemas__
  - __select_on_tables__

  rw:
  - ro
  - __insert__

  ddl:
  - rw
  - __all_on_schemas__

rules:
- grant:
    privilege: ddl
    database: mydb
    role: admins

Имя встроенного профиля подчиняется следующим нестрогим правилам:

В этом разделе не описан стандарт SQL и значение каждого права SQL. За подробностями о правах SQL обратитесь к документации команд GRANT и ALTER DEFAULT PRIVILEGES.

Справка по ACL #

Ниже приведён список встроенных списков ACL.

Для действующих прав:

Список ACL ALL ... IN SCHEMA проверяет, предоставлено ли право только подмножеству объектов. Это называется частичное предоставление права (partial grant). Частично предоставленное право или отзывается, если оно не нужно, или предоставляется заново, если ожидается.

Дать ссылку на эти списки ACL можно, используя параметр privileges: on в YAML. Пример:

privileges:
  myprofile:
  - type: SELECT
    on: ALL TABLES IN SCHEMA

Права по умолчанию ссылаются на тип права и класс объектов. ldap2pg проверяет права по умолчанию для следующих классов объектов:

В профиле прав необходимо дать ссылку на класс объектов с помощью параметра object в YAML.

Настроить пользовательский ACL пока невозможно.

Справка по профилям #

Справка по правам #

Ниже приведён список предопределённых прав:

Справка по правам по умолчанию #

Ниже приведён список предопределённых прав по умолчанию. В профиле прав по умолчанию даётся ссылка на права по умолчанию, которые действуют на глобальном уровне и на уровне схемы.

Конфигурирование pg_hba.conf через LDAP #

ldap2pg НЕ настраивает Postgres Pro за пользователя. Для конфигурирования Postgres Pro внимательно прочитайте Раздел 19.10. Перед написанием ldap2pg.yaml стоит надлежащим образом настроить Postgres Pro. Ниже приведёны шаги для настройки Postgres Pro через LDAP в рекомендуемом порядке:

После настройки аутентификации LDAP в кластере Postgres Pro можно переходить к автоматизации процесса создания ролей из каталога LDAP с помощью ldap2pg:

Поиск в каталоге LDAP #

Первый шаг — выполнить поиск в вашем сервере LDAP с помощью ldapsearch(1), утилиты командной строки из дистрибутива OpenLDAP. Пример:

$ ldapsearch -H ldaps://ldap.ldap2pg.docker -U testsasl -W
Enter LDAP Password:
SASL/DIGEST-MD5 authentication started
SASL username: testsasl
SASL SSF: 128
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
...
# search result
search: 4
result: 0 Success

# numResponses: 16
# numEntries: 15
$

Сохраните настройки в файле ldaprc:

LDAPURI ldaps://ldap.ldap2pg.docker
LDAPSASL_AUTHCID testsasl

И в окружении: LDAPPASSWORD=secret

Затем обновите ldapsearch, чтобы правильно сопоставить записи ролей на сервере LDAP:

$ ldapsearch -H ldaps://ldap.ldap2pg.docker -U testsasl -W -b cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker '' member
...
# dba, groups, ldap.ldap2pg.docker
dn: cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker
member: cn=Alan,ou=people,dc=ldap,dc=ldap2pg,dc=docker
member: cn=albert,ou=people,dc=ldap,dc=ldap2pg,dc=docker
member: cn=ALICE,ou=people,dc=ldap,dc=ldap2pg,dc=docker

# search result
search: 4
result: 0 Success

...
$

Теперь перенесите запрос в ldap2pg.yaml и установите сопоставление ролей, чтобы создавать роли из каждого значения каждой записи, которую возвращает поисковой запрос LDAP:

- ldapsearch:
    base: cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker
  role:
    name: '{member.cn}'
    options: LOGIN SUPERUSER

Выполните проверку:

$ ldap2pg
...
Querying LDAP cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker...
Would create alan.
Would create albert.
Would update options of alice.
...
Comparison complete.
$

За подробностями о том, как управлять созданием ролей из записи LDAP, обратитесь к разделу Конфигурация. Когда результат сравнения будет удовлетворительным, перейдите в режим действия с помощью --real.

Использование отказоустойчивости LDAP #

Встроенный функционал ldap2pg включает поддержку отказоустойчивости LDAP точно так же, как расширение поддерживает любого клиента OpenLDAP. Чтобы указать все серверы, перечислите их URI через пробел.

$ LDAPURI="ldaps://ldap1 ldaps://ldap2" ldap2pg

За подробностями обратитесь к ldap.conf(5).

Запуск не от имени суперпользователя #

Поскольку у ролей в Postgres Pro есть атрибут CREATEROLE, управлять ролями можно без прав суперпользователя. С точки зрения безопасности лучше управлять ролями без прав суперпользователя.

ldap2pg поддерживает такой сценарий. Однако стоит внимательно относиться к ограничениям. Назовем роль не суперпользователя, которая даёт возможность создавать другие роли, creator.

Удаление всех ролей #

Если в какой-то момент потребуется удалить все роли в кластере Postgres Pro, использовать расширение ldap2pg будет эффективно. Для удаления ролей явно определите пустые правила (rules).

$ echo '{version: 6, rules: []}' | ldap2pg --config -
...
Empty synchronization map. All roles will be dropped!
...

В этом примере применяется чёрный список по умолчанию. ldap2pg никогда не удаляет свою роль, которую использует для установки соединения.

ldap2pg как Docker-контейнер #

Предполагается, что это не первая встреча пользователя с Docker, поэтому в этом разделе настройки описаны не будут.

Чтобы запустить контейнер, используйте следующую команду:

$ docker run --rm dalibo/ldap2pg --help

В образе Docker для ldap2pg используются те же конфигурационные параметры, которые описаны в разделах Интерфейс командной строки и ldap2pg.yml. Можно подключить файл конфигурации ldap2pg.yml.

$ docker run --rm -v ${PWD}/ldap2pg.yml:/workspace/ldap2pg.yml dalibo/ldap2pg

Можно также экспортировать некоторые переменные окружения с помощью параметра -e:

$ docker run --rm -v ${PWD}/ldap2pg.yml:/workspace/ldap2pg.yml -e PGDSN=postgres://postgres@localhost:5432/ -e LDAPURI=ldaps://localhost -e LDAPBINDDN=cn=you,dc=entreprise,dc=fr -e LDAPPASSWORD=pasglop dalibo/ldap2pg

Убедитесь, что контейнер может разрешить имя компьютера, на который даётся указание. При использовании внутренних разрешений имени не забудьте добавить к вашей команде параметр -dns=, который указывает на ваш внутренний DNS-сервер. За подробностями обратитесь сюда.

Вариант использования #

Предположим, в вашей базе данных есть пользовательский тип enum myenum.

CREATE TYPE public.myenum AS ENUM ('toto', 'titi', 'tata');

Нам нужно получить доступ к управлению правами для этого объекта, в конечном итоге для других типов, через пользовательский ACL.

Определение имени #

Назовите ваш ACL по ключевому слову в операторе GRANT или REVOKE. Из GRANT USAGE ON TYPE mytype TO myrole определите имя для TYPE вашего ACL.

acls:
  TYPE:
    ...

Область действия #

Postgres Pro определяет типы пользователей в рамках схемы. Поскольку схема будет чётко задана, ограничим действие ACL базой данных.

acls:
  TYPE:
    scope: database

Предоставление и отзыв прав #

Написать операторы GRANT и REVOKE легче всего. За подробностями о формате запроса обратитесь к описанию предоставления прав. Используем поле object в параметре grant, чтобы поместить туда имя типа. Схема public жёстко задана, о чём было сказано выше.

acls:
  TYPE:
    scope: database
    grant: GRANT <privilege> ON TYPE public.<object> TO <grantee>;
    revoke: REVOKE <privilege> ON TYPE public.<object> FROM <grantee>;

Проверка #

Запрос на проверку — это самая сложная часть. Нужно уметь работать со встроенным системным типом Postgres Pro aclitem и встроенными системными функциями aclexplode и acldefault. Сигнатура запроса на проверку зависит от области действия ACL.

Для области действия instance:

Для области действия database:

Параметр partial указывает ldap2pg, что нужно снова предоставить права ALL ... IN SCHEMA. Поскольку наш ACL обрабатывает объекты по одному, значение partial всегда будет false.

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

Для списка ACL TYPE проверим права для доступа к системному каталогу pg_type.

acls:
  TYPE:
    scope: database
    grant: GRANT <privilege> ON <acl> public.<object> TO <grantee>;
    revoke: REVOKE <privilege> ON <acl> public.<object> FROM <grantee>;
    inspect: |
      WITH grants AS (
        SELECT typname,
               (aclexplode(COALESCE(typacl, acldefault('T', typowner)))).privilege_type AS priv,
               (aclexplode(COALESCE(typacl, acldefault('T', typowner)))).grantee::regrole::text AS grantee
          FROM pg_catalog.pg_type
        WHERE typnamespace::regnamespace = 'public'::regnamespace
          AND typtype <> 'b'  -- exclude base type.
      )
      SELECT grants.priv AS "privilege",
            grants.typname AS "object",
            CASE grants.grantee WHEN '-' THEN 'public' ELSE grants.grantee END AS grantee,
            FALSE AS partial
        FROM grants
      WHERE "priv" = ANY ($1)
      ORDER BY 2, 3, 1
      ;

Видно, что это не простой запрос. Он поддерживается в версии Postgres Pro 17.

Использование #

Теперь можно переходить к использованию вашего пользовательского ACL в профиле. Ссылайтесь на объект в профиле, а не в правиле предоставлении права.

privileges:
  custom:
  - type: USAGE
    on: TYPE
    object: myenum

rules:
- roles:
    names:
    - alice
  grant:
    privilege: custom
    role: alice

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

$ ldap2pg
...
16:52:02 CHANGE Would Revoke privileges.                         grant="USAGE ON TYPE myenum TO public" database=db0
16:52:02 CHANGE Would Grant privileges.                          grant="USAGE ON TYPE myenum TO alice" database=db0
16:52:02 INFO   Comparison complete.                             searches=0 roles=1 queries=5 grants=1
16:52:02 INFO   Use --real option to apply changes.
16:52:02 INFO   Done.                                            elapsed=44.345229ms mempeak=1.6MiB ldap=0s inspect=28.992071ms sync=0s

На этом всё.

Отладка #

Если возникла проблема, изолируйте её. Ограничьте конфигурацию вашим пользовательским ACL. Синхронизируйте единственную роль, предоставьте ей права. Не используйте поисковые запросы LDAP, используйте только статические правила. Синхронизируйте единственную базу данных. Включите вывод отладочных сообщений с помощью параметра --verbose.

ldap2pg просматривает по очереди базы данных, затем списки ACL. Для каждого ACL выводится следующее сообщение:

В первой строке с информацией о вашем ACL присутствует атрибут записей acl=TYPE.

    17:13:35 DEBUG  Inspecting grants.                               acl=TYPE scope=database database=db0
    

Затем идут сообщения для проверки: запрос и аргументы. Для каждого предоставленного права появляется сообщение Found grant (найденное предоставленное право)..

17:13:35 DEBUG  Executing SQL query:
WITH grants AS (
...
WHERE "priv" = ANY ($1)
ORDER BY 2, 3, 1
;
 arg=[USAGE]
17:13:35 DEBUG  Found grant in Postgres instance.                grant="USAGE ON TYPE myenum TO public" database=db0

После этого ldap2pg расширяет предоставленные права, сгенерированные правилом. Для каждого сгенерированного предоставленного права выводится сообщение Wants grant (требуется предоставить право )..

17:13:35 DEBUG  Wants grant.                                     grant="USAGE ON TYPE myenum TO alice" database=db0

В конце ldap2pg выводит изменения, которые будут применены.

17:13:35 CHANGE Would Revoke privileges.                         grant="USAGE ON TYPE myenum TO public" database=db0
17:13:35 DEBUG  Would Execute SQL query:
REVOKE USAGE ON TYPE public."myenum" FROM "public";
17:13:35 CHANGE Would Grant privileges.                          grant="USAGE ON TYPE myenum TO alice" database=db0
17:13:35 DEBUG  Would Execute SQL query:
GRANT USAGE ON TYPE public."myenum" TO "alice";

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

17:13:35 DEBUG  Privileges synchronized.                         acl=TYPE database=db0