🛠️ Прямой SELECT под ограниченной ролью возвращает ожидаемые строки, под сервисной — ещё одну. Политика RLS существует, но это не доказывает, что она действует для обеих ролей.
Учебная ситуация для PostgreSQL 18 с условной таблицей demo.rls_example: одинаковый запрос в двух сеансах с разными ролями. SELECT sample_id FROM demo.rls_example ORDER BY sample_id; Вымышленные результаты: limited_role → 101, 102; service_role → 101, 102, 103. Запрос не запускался. Такое расхождение ещё не называет причину. Реальные строки, имена и условия политик перед передачей результатов обезличьте.
Первая развилка — фактический контекст запроса. Для диагностики своей таблицы замените схему и имя в двух запросах к каталогам ниже. Выполните их в тех же сеансах и ролях, где обнаружили расхождение: SELECT current_user AS active_role, owner.rolname AS table_owner, c.relrowsecurity AS rls_on, c.relforcerowsecurity AS force_owner, pg_catalog.row_security_active(c.oid) AS rls_active, actor.rolsuper AS is_superuser, actor.rolbypassrls AS bypasses_rls FROM pg_catalog.pg_class AS c JOIN pg_catalog.pg_roles AS owner ON owner.oid = c.relowner JOIN pg_catalog.pg_roles AS actor ON actor.rolname = current_user WHERE c.oid = pg_catalog.to_regclass('demo.rls_example'); Пустой ответ этого запроса к pg_class — повод проверить текущую базу, схему и имя объекта, а не заключать, что RLS отключена.
rls_on показывает настройку таблицы; rls_active — действует ли RLS для текущей роли. Если rls_on = true, а rls_active = false, проверьте superuser, BYPASSRLS и права владельца, включая унаследованные при выключенном force_owner. Разные имена active_role и table_owner не исключают обход. FORCE ROW LEVEL SECURITY подчиняет владельца политике, но не отменяет обход superuser и BYPASSRLS.
rls_active = true подтверждает применение RLS; правильность границы доступа проверяется отдельно по применимым политикам: SELECT policyname, roles, cmd, qual FROM pg_catalog.pg_policies WHERE schemaname = 'demo' AND tablename = 'rls_example'; Для прямого SELECT проверьте cmd = SELECT или ALL, roles с учётом PUBLIC и членства, qual как условие USING. Отсутствие применимой политики при действующей RLS закрывает строки по умолчанию — это не причина дополнительных строк. Если применимых политик несколько, один qual не показывает итоговую видимость: важно их сочетание. Подробная логика сочетания выходит за рамки этой диагностики. Сохранённая политика при rls_on = false строки не фильтрует.
Типичная ошибка — менять правило после теста под другой ролью. Полезнее пройти путь от различия результатов через rls_active к возможному обходу и всем применимым политикам. Сохраните порядок проверки роли и политики; такие границы доступа полезно разбирать на практике администрирования PostgreSQL.
🔹🔹🔹🔹
