×
Мы обрабатываем cookies, чтобы сделать наш сайт удобнее и персонализированнее для вас. Подробнее: политика использования «cookies» и «политики конфиденциальности».

Для самостоятельной настройки ознакомьтесь с инструкцией

Дополнительные настройки cookies в браузерах

Файлы cookie автоматически загружаются в ваш браузер при посещении веб-сайта. У вас есть возможность управлять этими файлами. Если Вы не согласны с использованием файлов cookies, запретите их сохранение на своём устройстве, удалите уже имеющиеся файлы cookies через настройки браузера или прекратите использование сайта.

При отключении обработки cookie наш сайт продолжит функционировать, однако будут использоваться исключительно необходимые технические файлы, без которых работа ресурса невозможна.

Инструкция по отключению cookies
Принять
Настроить
Отклонить

ДОКУМЕНТАЦИЯ

Выберите версию, форк и язык для СУБД Digital Q.DataBase, чтобы прочитать или скачать всю документацию.
Техподдержка
Документация
Диасофт
Авторские права © 2016–2025 ООО "Диасофт Экосистема"
Скачать всю документацию:

6.1.148. GRANT

6.1.148. GRANT

GRANT — определение привилегий доступа

Синтаксис

GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER | MAINTAIN }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { [ TABLE ] table_name [, ...]
         | ALL TABLES IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
    [, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
    ON [ TABLE ] table_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { SEQUENCE sequence_name [, ...]
         | ALL SEQUENCES IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
    ON DATABASE database_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON DOMAIN domain_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN DATA WRAPPER fdw_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN SERVER server_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { EXECUTE | ALL [ PRIVILEGES ] }
    ON { { FUNCTION | PROCEDURE | ROUTINE } routine_name [ ( [ [ argmode ] [ arg_name ] arg_type [, ...] ] ) ] [, ...]
         | ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON LANGUAGE lang_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
    ON LARGE OBJECT loid [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { SET | ALTER SYSTEM } [, ... ] | ALL [ PRIVILEGES ] }
    ON PARAMETER configuration_parameter [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMA schema_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { CREATE | ALL [ PRIVILEGES ] }
    ON TABLESPACE tablespace_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON TYPE type_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT role_name [, ...] TO role_specification [, ...]
    [ WITH { ADMIN | INHERIT | SET } { OPTION | TRUE | FALSE } ]
    [ GRANTED BY role_specification ]

где role_specification может быть:

    [ GROUP ] role_name
  | PUBLIC
  | CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER

Описание

Команда GRANT имеет два основных варианта: один предоставляет привилегии на объект базы данных (таблицу, столбец, представление, стороннюю таблицу, последовательность, базу данных, обертку сторонних данных, сторонний сервер, функцию, процедуру, процедурный язык, большой объект, параметр конфигурации, схему, табличное пространство или тип), а другой предоставляет членство в роли. Эти варианты во многом схожи, но они достаточно различаются, чтобы рассматривать их по отдельности.

GRANT для объектов базы данных

Данный вариант команды GRANT предоставляет определенные привилегии на объект базы данных одной или нескольким ролям. Эти привилегии добавляются к уже предоставленным, если таковые имеются.

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

Если WITH GRANT OPTION указано, получатель привилегии может, в свою очередь, предоставить её другим. Без права передачи привилегии получатель не может этого сделать. Опции предоставления привилегий не могут быть предоставлены PUBLIC.

Если GRANTED BY указано, лицо, предоставляющее привилегию (grantor), должно быть текущим пользователем. Это предложение в настоящее время присутствует в данной форме только для совместимости со стандартом SQL.

Нет необходимости предоставлять привилегии владельцу объекта (обычно пользователю, который его создал), так как владелец обладает всеми привилегиями по умолчанию. (Однако владелец может, тем не менее, отозвать некоторые из своих собственных привилегий в целях безопасности.)

Право на удаление объекта или любое изменение его определения не рассматривается как предоставляемая привилегия; оно является неотъемлемым правом владельца и не может быть предоставлено или отозвано. (Однако аналогичный эффект может быть достигнут путем предоставления или отзыва членства в роли, владеющей объектом; см. ниже.) Владелец также неявно обладает всеми правами на предоставление привилегий для этого объекта.

Возможные привилегии:

SELECT
INSERT
UPDATE
DELETE
TRUNCATE
REFERENCES
TRIGGER
CREATE
CONNECT
TEMPORARY
EXECUTE
USAGE
SET
ALTER SYSTEM
MAINTAIN

Конкретные типы привилегий, определенные в Раздел 2.2.8.

TEMP

Альтернативное написание для TEMPORARY.

ALL PRIVILEGES

Предоставление всех привилегий, доступных для данного типа объекта. Ключевое слово PRIVILEGES является необязательным в Digital Q.DataBase, хотя оно требуется согласно строгому стандарту SQL.

Команда FUNCTION синтаксис подходит для обычных функций, агрегатных функций и оконных функций, но не для процедур; используйте PROCEDURE для них. В качестве альтернативы используйте ROUTINE для обращения к функции, агрегатной функции, оконной функции или процедуре независимо от её точного типа.

Также существует возможность предоставить привилегии на все объекты одного типа в рамках одной или нескольких схем. Эта функциональность в настоящее время поддерживается только для таблиц, последовательностей, функций и процедур. ALL TABLES также затрагивает представления и сторонние таблицы, аналогично команде для конкретного объекта GRANT команда. ALL FUNCTIONS также затрагивает агрегатные и оконные функции, но не процедуры, аналогично команде для конкретного объекта GRANT команда. Используйте ALL ROUTINES для включения процедур.

GRANT для ролей

Данный вариант команды GRANT команда предоставляет членство в роли одной или нескольким другим ролям, а также позволяет изменять параметры членства SET, INHERIT, и ADMIN; см. Раздел 3.6.3 для получения подробной информации. Членство в роли имеет важное значение, поскольку оно потенциально открывает доступ к привилегиям, предоставленным роли, каждому из ее участников, а также, возможно, дает возможность вносить изменения в саму роль. Однако фактически предоставляемые права доступа зависят от параметров, связанных с операцией GRANT. Чтобы изменить эти параметры для существующего членства, просто укажите членство с обновленными значениями параметров.

Каждый из описанных ниже параметров может быть установлен в значение TRUE или FALSE. Ключевое слово OPTION принимается в качестве синонима для TRUE, так что WITH ADMIN OPTION является синонимом WITH ADMIN TRUE. При изменении существующего членства отсутствие параметра приводит к сохранению его текущего значения.

Команда ADMIN параметр позволяет участнику, в свою очередь, предоставлять членство в роли другим пользователям, а также отзывать его. Без административной опции (admin option) обычные пользователи не могут этого делать. Роль не считается обладающей WITH ADMIN OPTION самой себе. Суперпользователи базы данных могут предоставлять или отзывать членство в любой роли для любого пользователя. Этот параметр по умолчанию принимает значение FALSE.

Команда INHERIT параметр управляет статусом наследования нового членства; см. Раздел 3.6.3 для получения подробной информации о наследовании. Если установлено значение TRUE, новый участник будет наследовать права предоставленной роли. Если установлено значение FALSE, новый участник не наследует права. Если этот параметр не указан при создании членства в роли, по умолчанию используется значение атрибута наследования нового участника.

Команда SET параметр, если он установлен в значение TRUE, позволяет участнику переключиться на предоставленную роль с помощью команды SET ROLE command. Если роль является косвенным участником другой роли, она может использовать SET ROLE для переключения на эту роль только при наличии цепочки предоставлений прав, каждое из которых имеет SET TRUE. Этот параметр по умолчанию принимает значение TRUE.

Для создания объекта, принадлежащего другой роли, или передачи права владения существующим объектом другой роли необходимо иметь возможность выполнять SET ROLE для этой роли; в противном случае такие команды, как ALTER ... OWNER TO или CREATE DATABASE ... OWNER завершатся ошибкой. Однако пользователь, наследующий привилегии роли, но не имеющий возможности выполнять SET ROLE этой роли могут получить полный доступ к роли путём манипулирования существующими объектами, принадлежащими этой роли (например, они могут переопределить существующую функцию, чтобы она действовала как «троянский конь»). Таким образом, если привилегии роли должны наследоваться, но не должны быть доступны через SET ROLE, она не должна владеть какими-либо объектами SQL.

Если GRANTED BY указана, операция предоставления прав записывается как выполненная указанной ролью. Пользователь может назначить права от имени другой роли только в том случае, если он обладает привилегиями этой роли. Роль, указанная в качестве предоставляющей права, должна иметь ADMIN OPTION для целевой роли, если только это не начальный суперпользователь. Когда операция предоставления прав записывается как выполненная лицом, отличным от начального суперпользователя, она зависит от сохранения за предоставляющим лицом ADMIN OPTION для этой роли; таким образом, если ADMIN OPTION отзывается, зависимые предоставления также должны быть отозваны.

В отличие от случая с привилегиями, членство в роли не может быть предоставлено для PUBLIC. Обратите также внимание, что эта форма команды не допускает использование вспомогательного слова GROUP в role_specification.

Примечания

Команда REVOKE используется для отзыва привилегий доступа.

Начиная с версии Digital Q.DataBase 8.1, концепции пользователей и групп были объединены в единый тип сущности, называемый ролью. Поэтому больше не требуется использовать ключевое слово GROUP для определения того, является ли получатель прав пользователем или группой. GROUP по-прежнему допускается в команде, но является избыточным словом.

Пользователь может выполнять SELECT, INSERT, и т. д. для столбца, если он обладает этой привилегией либо для конкретного столбца, либо для всей таблицы в целом. Предоставление привилегии на уровне таблицы с последующим её отзывом для одного столбца не даст желаемого результата: на права, предоставленные на уровне таблицы, операция на уровне столбца не влияет.

Когда лицо, не являющееся владельцем объекта, пытается GRANT привилегии для объекта, команда завершится ошибкой, если у пользователя нет вообще никаких привилегий для этого объекта. Если доступна хотя бы какая-то привилегия, выполнение команды будет продолжено, но будут предоставлены только те привилегии, для которых у пользователя есть право передачи (grant options). Формы GRANT ALL PRIVILEGES выведут предупреждение, если права передачи отсутствуют, в то время как другие формы выведут предупреждение, если права передачи отсутствуют для любой из привилегий, явно указанных в команде. (В принципе, эти положения применимы и к владельцу объекта, но так как владелец всегда считается обладающим всеми правами передачи, такие случаи никогда не возникают).

Следует отметить, что суперпользователи базы данных имеют доступ ко всем объектам независимо от настроек привилегий объектов. Это сопоставимо с правами root в системе Unix. Как и в случае с root, не рекомендуется работать от имени суперпользователя за исключением случаев крайней необходимости.

Если суперпользователь решит выполнить команду GRANT или REVOKE команда выполняется так, как если бы она была инициирована владельцем соответствующего объекта. В частности, будет считаться, что привилегии, предоставленные с помощью такой команды, были даны владельцем объекта. (В случае членства в роли будет считаться, что оно было предоставлено начальным суперпользователем.)

GRANT и REVOKE также может быть выполнено ролью, которая не является владельцем соответствующего объекта, но входит в роль, владеющую объектом, либо является членом роли, обладающей привилегиями WITH GRANT OPTION для этого объекта. В этом случае будет зафиксировано, что привилегии были предоставлены той ролью, которая фактически владеет объектом или обладает привилегиями WITH GRANT OPTION. Например, если таблица t1 принадлежит роли g1, членом которой является роль u1 , то u1 может предоставлять привилегии на t1 роли u2, но будет считаться, что эти привилегии были предоставлены непосредственно g1. Любой другой участник роли g1 может отозвать их позже.

Если роль, выполняющая GRANT обладает необходимыми привилегиями косвенно через несколько путей членства в ролях, не определено, какая именно из вышестоящих ролей будет записана как предоставившая привилегию. В таких случаях рекомендуется использовать SET ROLE , чтобы принять конкретную роль, от имени которой вы хотите выполнить GRANT .

Предоставление прав доступа к таблице не распространяет привилегии автоматически на любые последовательности, используемые таблицей, включая последовательности, связанные со SERIAL столбцами. Привилегии для последовательностей должны быть установлены отдельно.

См. Раздел 2.2.8 для получения дополнительной информации о конкретных типах привилегий, а также о том, как проверять привилегии объектов.

Примеры

Предоставление привилегии на вставку (INSERT) всем пользователям для таблицы films:

GRANT INSERT ON films TO PUBLIC;

Предоставление всех доступных привилегий пользователю manuel для представления kinds:

GRANT ALL PRIVILEGES ON kinds TO manuel;

Обратите внимание, что хотя приведенная выше команда действительно предоставит все привилегии, если она будет выполнена суперпользователем или владельцем kinds, при выполнении кем-то другим она предоставит только те права доступа, на которые у этого пользователя есть право передачи привилегий (grant options).

Предоставление членства в роли admins пользователю joe:

GRANT admins TO joe;

Совместимость

Согласно стандарту SQL, PRIVILEGES ключевое слово в ALL PRIVILEGES является обязательным. Стандарт SQL не поддерживает назначение привилегий более чем для одного объекта одной командой.

Digital Q.DataBase позволяет владельцу объекта отзывать собственные обычные привилегии: например, владелец таблицы может сделать её доступной только для чтения для самого себя, отозвав свои собственные INSERT, UPDATE, DELETE, и TRUNCATE привилегии. Это невозможно согласно стандарту SQL. Причина заключается в том, что Digital Q.DataBase рассматривает привилегии владельца как предоставленные владельцем самому себе; следовательно, он может их отозвать. В стандарте SQL привилегии владельца предоставляются некоей условной сущностью «_SYSTEM». Не являясь «_SYSTEM», владелец не может отозвать эти права.

Согласно стандарту SQL, право передачи привилегий может быть предоставлено PUBLIC; PostgreSQL поддерживает предоставление права передачи привилегий только ролям.

Стандарт SQL допускает GRANTED BY возможность указывать только CURRENT_USER или CURRENT_ROLE. Остальные варианты являются расширениями PostgreSQL.

Стандарт SQL предусматривает USAGE привилегию для других типов объектов: наборов символов, правил сортировки, перекодировок.

В стандарте SQL для последовательностей предусмотрена только USAGE привилегия, управляющая использованием NEXT VALUE FOR выражения, эквивалентного функции nextval в PostgreSQL. Привилегии для последовательностей SELECT и UPDATE являются расширениями PostgreSQL. Применение привилегии USAGE последовательности к функции currval также является расширением PostgreSQL (как и сама функция).

Привилегии на базы данных, табличные пространства, схемы, языки и параметры конфигурации являются Digital Q.DataBase расширениями.

Наверх
свяжитесь
с нами
контакты
Для прямой связи с нами вы можете использовать контакты ниже, либо оставить заявку через форму обратной связи, и мы обязательно свяжемся с вами

*поля обязательные к заполнению