Есть ли простой способ перечислить все объекты, к которым у определенной роли есть привилегия доступа? Я знаю, что набор функций has_*_privilege
в pg_catalog, но они не выполняют эту работу, я хочу работать наоборот. Фактически я хочу иметь представление, которое дает права доступа и доступа к чему-либо, хранящемуся в pg_class, для определенной роли.
Такое мнение было бы чрезвычайно полезно проверить, правильно ли настроена безопасность базы данных. Как правило, гораздо меньше ролей, чем отношений, поэтому проверка роли намного менее обременительна ИМХО. Должна ли такая утилита недоступна в стандартном распределении PostgreSQL?
Согласно исходному коду (acl.h), aclitem является структурой:
typedef struct AclItem
{ Oid ai_grantee; /* ID that this item grants privs to */
Oid ai_grantor; /* grantor of privs */
AclMode ai_privs; /* privilege bits */
} AclItem;
Легко работать. Однако pg_type перечисляет это как определяемый пользователем некомпозитный тип. Почему это? Единственный способ, который я вижу сейчас, - проанализировать массив aclitem [], используя строковые функции. Есть ли лучший способ анализа массива aclitem?
Добавленная информация. Просматривая различные списки PG, очевидно, что эта проблема продолжает появляться в разных формах, по крайней мере, с 1997 года (у нас были компьютеры, тогда были телевизоры вокруг?), Что наиболее актуально в дискуссионном потоке "Binary in/out for aclitem "на pgsql-хакерах в начале 2011 года. Поскольку (технически квалифицированный) пользователь, а не хакер, PG, я ценю заботу разработчиков о поддержании стабильного интерфейса, но некоторые из озабоченностей, озвученных в потоке, немного далеко за мои вкусы. Какова реальная причина не иметь таблицу pg_acl в системных каталогах с определением, равным структуре AclItem в исходном коде? Когда эта структура изменилась? Я также знаю о событиях SE, которые, скорее всего, вносят изменения в способ обработки безопасности - когда пользователи предпочитают, предположительно, поэтому я соглашусь на то, что представляет acl-информацию таким образом, что легко перечислять предоставленные привилегии для конкретный пользователь, такой как:
SELECT * FROM pg_privileges WHERE grantee = 16384;
Таким образом, он все равно может быть абстракцией базовых структур, поэтому любые изменения под капотом могут затем (предположительно) быть переведены в открытый интерфейс. Я бы сказал, не слишком отличается от подхода information_schema.
Привет, Патрик