Postgres Разрешения - PullRequest
Новая
       7

Postgres Разрешения

1 голос
/ 06 февраля 2020

У меня проблемы с пониманием привилегий в PostgreSQL.

Например, у меня есть веб-приложение с пользователем webapiuser. Этот пользователь ограничен в том смысле, что он может работать с базой данных только через какую-то функцию. Это означает, что нет прямых операций CRUD с БД, только с помощью функций, созданных пользователем god postgres и только в пределах его собственного домена . Я сделал все виды чтения со многими учебными пособиями, указывающими на добавление SECURITY DEFINER к каждой функции, но это позволяет функции выполняться владельцем функции от имени пользователя, который побеждает цель в моем понимание; В конце концов я пытаюсь заблокировать такого рода доступ.

Я уже создал пользователя с: 

CREATE USER webapiuser WITH PASSWORD <password>;

И предоставил USAGE для всех схем: 

GRANT USAGE ON SCHEMA schemaA TO webapiuser;
GRANT USAGE ON SCHEMA schemaB TO webapiuser;
GRANT USAGE ON SCHEMA poublic TO webapiuser;

Я пытался добавить: 

GRANT EXECUTE ON FUNCTION schemaA.func_myfunction() TO webapiuser;

Но тогда я получил permission denied for view view_my_view. Функция выбирает из этого представления, поэтому я думаю, что команда GRANT работает. Я получаю похожую ошибку permission denied for table my_table, если я выполняю функцию, которая выполняет операции вставки. Как далеко вниз по привилегированной кроличьей норе я должен go выполнить эту, казалось бы, простую задачу? И если я предоставлю INSERT, UPDATE, DELETE привилегии этому пользователю для этих таблиц напрямую, то это противоречит цели.

Не должно ли предоставление пользователю EXECUTE разрешений для функции, позволяющих это сделать что-нибудь в рамках этой функции?

1 Ответ

1 голос
/ 06 февраля 2020

Позвольте мне начать с того, что меня удивляет, как многие думают, что это лучший способ использовать функции для модификации данных. Кроме того факта, что планы кэширования функций PL / pg SQL (которые вы также можете иметь с подготовленными операторами), я не вижу в этом смысла.

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

Чтобы описать мое предложение, возьмите трех (обычных!) пользователей a, b и c:

  • a является владельцем схемы appschema, и объекты базы данных в этой схеме, то есть a, использовались для их создания. a предоставляет все необходимые права на объекты b, но не c.

  • b владеет набором SECURITY DEFINER функций, которые выполняют модификации данных на столах в appschema. b отзывает привилегию EXECUTE для этих функций с PUBLIC и предоставляет ее только c.

    Очень важно, чтобы все эти функции были определены с SET search_path = appschema.

  • c - это пользователь, который используется приложением. За исключением привилегии EXECUTE для функции b, этот пользователь не имеет разрешений, кроме права на подключение к базе данных.

Теперь, когда c выполняет любое из функции, они будут работать с пользовательским контекстом b, то есть они могут выполнять все операции, которые может b.

...