>> ролевая модель и правда доступа на объекты именно на уровне

СУБД? Мб в своё приложение добавить поддержку casbin / прикрутить ory.Kratos?

именно на уровне субд. Задача простая: нужно разделить доступы в рамках одного сервера между разными пользователями. И в рамках бд (что можно через hba.conf) и в рамках схем, объектов итд. Гугление дает лишь примеры уровня "раздай на все таблицы", "добавь правило на раздачу права Х пользователю Y при добавлении таблицы" и прочее подобное. А хотелось бы понимать как оно там внутри работает и как правильно в той или иной ситуации сделать.

можно примерно как тут: https://t.me/pgsql/246213 вы не сможете найти готового решения, т.к. оно зависит полностю от ваших особенностей. в целом, доступ делиться на следующие компоненты (3 уровня): - доступ к объектам в базе даётся группам доступа (в примере выше группы очень общие), например: ro/rw доступ к клиентским данным, к настройкам сервиса, к тарификации и т.д. - создаются целевые группы (ACL) по роду деятельности: операционисты, поддержка, админы, финансы и т.д., каждой целевой группе присваиваются нужные ей группы доступа - доступ целевым группам прописывается в pg_hba.conf - пользователей включают в нужные целевые группы

Права доступа вполне себе доступно и понятно описаны в документации. Глобальные привилегии ролей, пользователей - по команде CREATE ROLE: https://postgrespro.ru/docs/postgresql/11/sql-createrole из этой доки ведут ссылки на описание ролевой модели ПГ и способов аутентификации. Права доступа к объектам - по команде GRANT: https://postgrespro.ru/docs/postgresql/11/sql-grant Необходимо помнить, что командой GRANT вы выдаёте права только для УЖЕ СУЩЕСТВУЮЩИХ объектов! Для назначения прав по-умолчанию, используется команда ALTER DEFAULT PRIVILEGES: https://postgrespro.ru/docs/postgresql/11/sql-alterdefaultprivileges По транзакциям: https://postgrespro.ru/docs/postgresql/12/mvcc лучше прочитать всю главу, я думаю.

А жаль, что примеров так мало (и нет примеров типичных схем раздачи прав), IMHO. Потому что если пытаться этим заниматься всерьёз, а не просто "да мы всё в приложении спрячем и проконтролируем", можно неожиданно (а если нужно RLS — вообще запросто, мне кажется) "влететь", и это из документации не очевидно (и информация, к тому же, разбросана по разным разделам). В общем, Вы видели где-то хорошее описание принципов схем раздачи прав на примерах?

на примерах — нет. всё основано на опыте, как в Oracle, так и в Postgres. справедливости ради, хороших систем доступа встречал мало, и они в целом были похожи между собой (как я описал выше). с RLS проявляются косяки в планировании запросов, но пока получалось обходить незначительными изменениями самих запросов

Жаль. > и они в целом были похожи между собой Мне кажется, что если при этом подходе "ляпнуть" в какой-то мелочи, можно запросто открыть (и даже для изменений) то, что совсем не планировалось. > с RLS проявляются косяки в планировании запросов Да я же не об этом. У меня ощущение, что на самом деле многие из т.н. RLS (особенно, если они не основаны на встроенных механизмах) — это "решето". ;) Т.е. тот, кому это нужно и кто в этом разбирается, "вытащит" кучу той информации, которая ему совсем не предназначалась. :(

Почему нет типичных примеров - потому что пока не вот уж есть инсталляций в достаточном количестве, где права доступа разруливаются на уровне СУБД. Обычно на уровне приложения, а в БД ходит приклад под одной учётной записью. И второе - в каждой избушке свои погремушки. Надеюсь, этот факт не надо разъяснять. Ну и я считаю, как выше написал, что в документации достаточно информации, чтобы грамотно рулить правами доступа. Другое дело, что к этому рулению надо подходить аккуратно и вдумчиво, особенно при использовании функций для доступа к данным. И процедура эта - отнюдь не пятиминутная.

> пока не вот уж есть ... где права доступа разруливаются на уровне СУБД > Обычно на уровне приложения, а в БД ходит приклад под одной учётной записью. Что значит, что в этих случаях документация, фактически, не имеет отношения к делу, и это вариант "да мы всё в приложении спрячем и проконтролируем", нет? Или же, если это типичная схема, было бы неплохо, если бы принцип раздачи прав под неё был описан (с примерами и особенно её ограничениями / "врождёнными дефектами"), мне кажется. > в документации достаточно информации, чтобы грамотно рулить правами доступа. Формально-то да... Но (в качестве аналогии) и в стандарте SQL, например, "достаточно информации" для реализации conforming SQL implementation, но что-то все fail-ят (причём, по-разному) во многих случаях (включая PostgreSQL), хотя и стараются. ;) > Другое дело, что к этому рулению надо подходить аккуратно и вдумчиво Ну и было бы неплохо, если бы "типичные" подходы, решения и ошибки были описаны, чтобы не было, как с ISO SQL. А так описываются почти исключительно инструменты, а не то, как ими работать и что делать, я вот о чём. И я не имею в виду, что это должно быть в документации — книга, wiki или статья тут даже больше подходят.

> У меня ощущение, что на самом деле многие из т.н. RLS (особенно, если они не основаны на встроенных механизмах) — это "решето". 😉 вот это не понял. я под RLS подразумеваю только то, что база в этой области предоставляет. реализации по типу “у нас за всё приложение отвечает” встречал неоднократно, там всё печально с целостностью… исключений не было.

> вот это не понял. Я имел в виду в основном "самопальные" RLS, вместо того, что предоставляет PostgreSQL, т.е. "реализации по типу “у нас за всё приложение отвечает”", да. Но и даже на основе "настоящего" RLS не так уж сложно "накосить", как мне кажется.

В RLS проблема планировщика в том что операторы = и тд объявлены не как LEAKPROOF, не проверял в правда в последних версиях

какая конкретно проблема?

Политика с предикатом employer.idDepartment = .. В запросе select * from employer where Id = :pid не будет проталкиваться внутрь предиката

сделайте политику USING (idDepartment IS NOT DISTINCT FROM … )

id PK, id = :pid всегда будет выполнятся после любой политики Что крайне не эффективно