CREATE POLICY
CREATE POLICY — создать новую политику защиты на уровне строк для таблицы
Синтаксис
CREATE POLICYимя
ONимя_таблицы
[ AS { PERMISSIVE | RESTRICTIVE } ] [ FOR { ALL | SELECT | INSERT | UPDATE | DELETE } ] [ TO {имя_роли
| PUBLIC | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...] ] [ USING (выражение_USING
) ] [ WITH CHECK (выражение_CHECK
) ]
Описание
Команда CREATE POLICY
определяет для таблицы новую политику защиты на уровне строк. Заметьте, что для таблицы должна быть включена защита на уровне строк (используя ALTER TABLE ... ENABLE ROW LEVEL SECURITY
), чтобы созданные политики действовали.
Политика даёт разрешение на выборку, добавление, изменение или удаление строк, удовлетворяющих соответствующему выражению политики. Существующие строки таблицы проверяются по выражению, указанному в USING
, тогда как строки, которые могут быть созданы командами INSERT
или UPDATE
проверяются по выражению, указанному в WITH CHECK
. Когда выражение USING
истинно для заданной строки, эта строка видна пользователю, а если ложно или выдаёт NULL, строка не видна. Когда выражение WITH CHECK
истинно для заданной строки, эта строка добавляется или изменяется, а если ложно или выдаёт NULL, происходит ошибка.
Для операторов INSERT
, UPDATE
и MERGE
выражения WITH CHECK
применяются после срабатывания триггеров BEFORE
, но до того, как будут собственно модифицированы данные. Таким образом, триггер BEFORE ROW
может изменить данные, подлежащие добавлению, и повлиять на результат условия политики защиты. Выражения WITH CHECK
обрабатываются до каких-либо других ограничений.
Имена политик задаются на уровне таблицы. Таким образом, одно имя политики можно использовать в нескольких разных таблицах и в каждой дать отдельное, подходящее этой таблице определение политики.
Политики могут применяться для определённых команд или для определённых ролей. По умолчанию создаваемые политики применяются для всех команд и ролей, если явно не задано другое. К одной команде могут применяться несколько политик; подробнее рассказывается ниже. В Таблице 303 показано, как к определённым командам применяются разные типы политик.
Для политик, которые могут иметь и выражения USING
, и выражения WITH CHECK
(ALL
и UPDATE
), в случае отсутствия выражения WITH CHECK
выражение USING
будет использоваться и для определения видимости строк (обычное назначение USING
) и для определения, какие строки разрешено добавить (назначение WITH CHECK
).
Если для таблицы включена защита на уровне строк, но применимые политики отсутствуют, предполагается политика «запрета по умолчанию», так что никакие строки нельзя будет увидеть или изменить.
Параметры
имя
Имя создаваемой политики. Оно должно отличаться от имён других политик для этой таблицы.
имя_таблицы
Имя (возможно, дополненное схемой) существующей таблицы (или представления), к которой применяется эта политика.
PERMISSIVE
Указывает, что создаваемая политика должна быть разрешительной. Все разрешительные политики, которые применяются к данному запросу, будут объединяться вместе логическим оператором «ИЛИ». Создавая разрешительные политики, администраторы могут расширять множество записей, к которым можно обращаться. Политики являются разрешительными по умолчанию.
RESTRICTIVE
Указывает, что создаваемая политика должна быть ограничительной. Все ограничительные политики, которые применяются к данному запросу, будут объединяться вместе логическим оператором «И». Создавая ограничительные политики, администраторы могут сократить множество записей, к которым можно обращаться, так как для каждой записи должны удовлетворяться все ограничительные политики.
Заметьте, что для получения доступа к записям должна быть определена минимум одна разрешительная политика, и только в дополнение к ней могут быть определены имеющие смысл ограничительные политики, ограничивающие доступ. Если разрешительные политики отсутствуют, ни к каким записям обращаться нельзя. Когда определены и разрешительные, и ограничительные политики, запись будет доступна, если удовлетворяется минимум одна из разрешительных политик и все ограничительные.
команда
Команда, к которой применяется политика. Допустимые варианты:
ALL
,SELECT
,INSERT
,UPDATE
иDELETE
.ALL
(все) подразумевается по умолчанию. Особенности их применения описаны ниже.имя_роли
Роль (роли), к которой применяется политика. По умолчанию подразумевается
PUBLIC
, то есть политика применяется ко всем ролям.выражение_USING
Произвольное условное выражение SQL (возвращающее
boolean
). Это условное выражение не может содержать агрегатные или оконные функции. Когда включена защита на уровне строк, оно добавляется в запросы, обращающиеся к данной таблице, и в их результатах оказываются видимыми только те строки, для которых оно выдаёт true. Все строки, для которых это выражение возвращает false или NULL, не будут видны пользователю (в запросеSELECT
), и не будут доступны для модификации (запросамиUPDATE
илиDELETE
). Такая строка просто пропускается, ошибка при этом не выдаётся.выражение_CHECK
Произвольное условное выражение SQL (возвращающее
boolean
). Это условное выражение не может содержать агрегатные или оконные функции. Когда включена защита на уровне строк, оно применяется в запросахINSERT
иUPDATE
к этой таблице, так что в них принимаются только те строки, для которых оно выдаёт true. Если это выражение выдаёт false или NULL для любой из добавляемых записей или записей, получаемых при изменении, выдаётся ошибка. Заметьте, чтоограничение_проверки
вычисляется для предлагаемого нового содержимого строки, а не для существующих данных.
Политики по командам
ALL
#Указание
ALL
для политики означает, что она применяется ко всем командам, вне зависимости от типа. Если существует политикаALL
и другие более детализированные политики, тогда будет применяться и политикаALL
, и более детализированная политика (или политики). Кроме того, политикиALL
с выражениемUSING
будут применяться и к стороне выборки, и к стороне изменения данных в запросе, если определено только выражениеUSING
.Например, когда выполняется
UPDATE
, политикаALL
будет фильтровать и строки, которые сможет прочитатьUPDATE
для изменения (применяя выражениеUSING
), и окончательные изменённые строки, проверяя, можно ли записать их в таблицу (применяя выражениеWITH CHECK
, если оно определено, илиUSING
в противном случае). Если командаINSERT
илиUPDATE
пытается добавить в таблицу строки, не удовлетворяющие выражениюWITH CHECK
политикиALL
, вся команда будет прервана.SELECT
#Указание
SELECT
для политики означает, что она применяется к запросамSELECT
и тогда, когда при обращении к отношению, для которого определена политика, задействуется правоSELECT
. В результате запросSELECT
выдаст только те записи из отношения, которые удовлетворят политикеSELECT
, и запрос, использующий правоSELECT
, например, запросUPDATE
, увидит только записи, разрешённые политикойSELECT
. Для политикиSELECT
не может задаваться выражениеWITH CHECK
, так как оно действует только когда записи читаются из отношения.INSERT
#Указание
INSERT
для политики означает, что она применяется к командамINSERT
, а также к командамMERGE
с действиямиINSERT
. Если вставляемые строки не проходят проверку политики, выдаётся ошибка нарушения политики и вся командаINSERT
прерывается. Для политикиINSERT
не может задаваться выражениеUSING
, так как она действует только когда в отношение добавляются записи.Заметьте, что
INSERT
с указаниемON CONFLICT DO UPDATE
проверяет выраженияWITH CHECK
политикINSERT
только для строк, добавляемых в отношение по путиINSERT
.UPDATE
#Выбор типа
UPDATE
для политики означает, что она будет применяться к командамUPDATE
,SELECT FOR UPDATE
иSELECT FOR SHARE
, а также к дополнительным предложениямON CONFLICT DO UPDATE
командINSERT
. Это также касается командMERGE
с действиямиUPDATE
. Так какUPDATE
подразумевает извлечение существующей записи и замену её новой изменённой записью, политикиUPDATE
принимают как выражениеUSING
, так иWITH CHECK
. ВыражениеUSING
определяет, какие записи командаUPDATE
сможет увидеть для последующего изменения, а выражениеWITH CHECK
— какие изменённые строки сохранить в отношении.Если в какой-либо строке изменённые значения не будут удовлетворять выражению
WITH CHECK
, произойдёт ошибка и вся команда будет прервана. Если указывается только предложениеUSING
, его выражение будет применяться и в качествеUSING
, и в качестве выраженияWITH CHECK
.Обычно команде
UPDATE
также нужно прочитать данные из столбцов подлежащего изменению отношения (например, в предложенииWHERE
илиRETURNING
либо в выражении в правой части предложенияSET
). В этом случае также требуется иметь праваSELECT
в изменяемом отношении и в дополнение к политикамUPDATE
будут применяться соответствующие политикиSELECT
илиALL
. Таким образом, помимо того, что пользователю должны разрешать изменение строк политикиUPDATE
илиALL
, ему также должны разрешать доступ к изменяемым строкам политикиSELECT
илиALL
.Когда для команды
INSERT
задано вспомогательное предложениеON CONFLICT DO UPDATE
, если выбирается путьUPDATE
, строка, подлежащая изменению, сначала проверяется по выражениямUSING
всех политикUPDATE
, а затем изменённая строка ещё раз проверяется по выражениямWITH CHECK
. Заметьте, однако, что в отличие от отдельной командыUPDATE
, если существующая строка не удовлетворяет выражениямUSING
, будет выдана ошибка (путьUPDATE
никогда не пропускается неявно).DELETE
#Указание
DELETE
для политики означает, что она применяется к командамDELETE
. КомандаDELETE
будет видеть только те строки, которые позволит эта политика. При этом строки могут быть видны черезSELECT
, но удалить их будет нельзя, если они не удовлетворяют выражениюUSING
политикиDELETE
.В большинстве случаев команде
DELETE
также нужно прочитать данные из столбцов в отношении, из которого осуществляется удаление (например, в предложенииWHERE
илиRETURNING
). В таких случаях необходимо также иметь правоSELECT
для этого отношения, и в дополнение к политикамDELETE
будут применятся соответствующие политикиSELECT
илиALL
. Таким образом, пользователь должен получить доступ к удаляемым строкам через политикиSELECT
илиALL
, помимо того что удаление этих строк ему должны разрешить политикиDELETE
илиALL
.Для политики
DELETE
не может задаваться выражениеWITH CHECK
, так как она применяется только тогда, когда записи удаляются из отношения, а в этом случае новые строки, подлежащие проверке, отсутствуют.
Таблица 303. Политики, применяемые для разных команд
Команда | Политика SELECT/ALL | Политика INSERT/ALL | Политика UPDATE/ALL | Политика DELETE/ALL | |
---|---|---|---|---|---|
Выражение USING | Выражение WITH CHECK | Выражение USING | Выражение WITH CHECK | Выражение USING | |
SELECT | Существующая строка | — | — | — | — |
SELECT FOR UPDATE/SHARE | Существующая строка | — | Существующая строка | — | — |
INSERT / MERGE ... THEN INSERT | — | Новая строка | — | — | — |
INSERT ... RETURNING | Новая строка [a] | Новая строка | — | — | — |
UPDATE / MERGE ... THEN UPDATE | Существующие и новые строки [a] | — | Существующая строка | Новая строка | — |
DELETE | Существующая строка [a] | — | — | — | Существующая строка |
ON CONFLICT DO UPDATE | Существующие и новые строки | — | Существующая строка | Новая строка | — |
[a] Если для существующей или новой строки требуется доступ на чтение (например, предложение |
Применение нескольких политик
Когда к одной команде применяются несколько политик для различных типов команд (как например, политики SELECT
и UPDATE
применяются к команде UPDATE
), пользователь должен иметь разрешения всех этих типов (например, разрешение для выборки строк из отношения, а также разрешение на их изменение). Таким образом, выражения для одного типа политики комбинируются с выражениями для другого типа операцией И
.
Когда к одной команде применяются несколько политик для одного типа команды, доступ к отношению должна дать как минимум одна разрешительная (PERMISSIVE
) политика, а также должны удовлетворяться все ограничительные (RESTRICTIVE
) политики. Таким образом выражения всех политик PERMISSIVE
объединяются операцией ИЛИ
, выражения всех политик RESTRICTIVE
объединяются операцией И
, а полученные результаты объединяются операцией И
. Если политики PERMISSIVE
отсутствуют, доступ запрещается.
Заметьте, что при объединении нескольких политик, политики ALL
применяются как политики каждого применимого в данном случае типа.
Например, в команде UPDATE
, требующей разрешений и для SELECT
, и для UPDATE
, в случае существования нескольких применимых политик каждого типа они будут объединяться следующим образом:
выражение
from RESTRICTIVE SELECT/ALL policy 1 ANDвыражение
from RESTRICTIVE SELECT/ALL policy 2 AND ... AND (выражение
from PERMISSIVE SELECT/ALL policy 1 ORвыражение
from PERMISSIVE SELECT/ALL policy 2 OR ... ) ANDвыражение
from RESTRICTIVE UPDATE/ALL policy 1 ANDвыражение
from RESTRICTIVE UPDATE/ALL policy 2 AND ... AND (выражение
from PERMISSIVE UPDATE/ALL policy 1 ORвыражение
from PERMISSIVE UPDATE/ALL policy 2 OR ... )
Примечания
Чтобы создать или изменить политики для таблицы, нужно быть её владельцем.
Хотя политики применяются к явно выполняемым запросам к таблицам БД, они не применяются, когда система выполняет внутренние проверки ссылочной целостности или проверяет ограничения. Это означает, что существуют косвенные пути проверить существование заданного значения. Например, можно попытаться вставить повторяющееся значение в столбец, образующий первичный ключ или имеющую ограничение уникальности. Если при этом произойдёт ошибка, пользователь может заключить, что это значение уже существует. (В данном случае предполагается, что политика разрешает пользователю вставлять записи, которые он может не видеть.) Подобный приём также возможен, если пользователь может вставлять записи в таблицу, которая ссылается на другую, иным образом не видимую. Существование значения можно определить, вставив его в подчинённую таблицу, при этом успешный результат операции будет признаком того, что это значение есть в главной таблице. Эти изъяны можно устранить, либо тщательно разработав политики, которые вовсе не позволят пользователям выполнять операции добавления, изменения и удаления, по результатам которых можно узнать о значениях в таблицах, не видимых иным образом, либо используя генерируемые значения (например, суррогатные ключи).
Вообще система будет применять фильтры, устанавливаемые политиками безопасности, до условий в запросах пользователя, чтобы предотвратить нежелательную утечку защищаемых данных через пользовательские функции, которые могут быть недоверенными. Однако функции и операторы, помеченные системой (или системным администратором) как LEAKPROOF
(герметичные) могут вычисляться до условий политики, так как они считаются доверенными.
Так как выражения политики добавляются непосредственно в запрос пользователя, они выполняются с правами пользователя, запускающего исходный запрос. Таким образом, пользователи, на которых распространяется заданная политика, должны иметь права для обращения ко всем таблицам и функциям, задействованным в выражении, иначе им просто будет отказано в доступе при попытке обращения к целевой таблице (если для неё включена защита на уровне строк). Однако это не влияет на работу представлений — как и с обычными запросами и представлениями, проверки разрешений и политики для нижележащих таблиц представления будут выполняться с правами владельца представления, и при этом будут действовать политики, распространяющиеся на этого владельца, за исключением случаев, когда представление определяется с характеристикой security_invoker
(см. CREATE VIEW
).
Для MERGE
не существует отдельной политики. Когда выполняется MERGE
, в зависимости от фактически выполняемых действий применяются политики, определённые для SELECT
, INSERT
, UPDATE
и DELETE
.
Дополнительное описание и практические примеры можно найти в Разделе 5.9.
Совместимость
CREATE POLICY
является расширением Postgres Pro.