Как пояснил @Craig, вы не можете (и даже если бы могли, это было бы совершенно бессмысленно).
Обычный способ реализации ограниченных прав суперпользователя состоит в том, чтобы подключиться как существующая роль суперпользователя и создать SECURITY DEFINER functions, содержащий ограниченный набор утвержденных команд. Теперь эти функции будут выполняться с привилегиями создателя, а не вызывающего.
Но вам нужно быть очень, чтобы не открывать какие-либо инъекционные уязвимости, потому что все внутри функции будет запущено как суперпользователь. Например. вызывающий может написать пользовательский оператор =, который предоставляет им права суперпользователя и помещает его в свой путь поиска, поэтому вам нужно быть абсолютно уверенным, что вы используете = в схеме pg_catalog.
По крайней мере, вы должны:
- Создать все эти функции с пунктом
SECURITY DEFINER SET search_path TO pg_catalog, pg_temp. Схема pg_temp всегда должна быть включена в конец списка (если она опущена, она будет неявно включена в начале).
- Схемы - укажите любые другие таблицы, функции и т. Д., Которые ссылаются на вашу функцию (например,
public.MyTable, а не только MyTable), и убедитесь, что все они принадлежат суперпользователю (так что вызывающие абоненты не могут помещать вредоносный код в триггеры , и т.д.).
- Никогда не вводите пользовательский ввод в динамическую строку запроса (
EXECUTE 'SELECT ...') без исчерпывающей проверки.
Почему вы хотите это сделать? Какова основная проблема, которую вы пытаетесь решить здесь? –
У нас есть разные модули в нашем проекте, для каждого из модулей БД находятся на одном сервере. Поэтому хочу, чтобы модуль суперпользователей был специфичным, поэтому хотел применить его на индивидуальной основе. –
ОК, но зачем вам нужно быть суперпользователем? Вы уверены, что вам не нужны только они, чтобы быть владельцем базы данных? –