Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

Назначение привилегий роли

Для "загрузки" роли привилегиями просто предоставьте ей требуемые привилегии, как если бы роль была обычным пользователем:

GRANT <привилегии> ТО <имя-роли>;

Предоставление роли пользователям

В операторе GRANT для предоставления роли пользователям опускается предложение ON- здесь неявно используются полномочия, "загруженные" в роль.

GRANT <имя-роли> [, <имя-роли> [, ...]]

TO [DSER] <имя-пользователя> [, [OSER] <имя-пользователя> [, ...]] [WITH ADMIN OPTION];

Необязательное предложение WITH ADMIN OPTION позволяет получающему роль предоставлять эту роль другим пользователям, а также отменять ее. Это работает таким же образом, что и WITH GRANT OPTION для обычных полномочий - см. разд. "Предоставление прав на предоставление привилегий".

Следующий пример создает роль MAITRE D, предоставляет этой роли привилегии ALL К таблице DEPARTMENT, а затем предоставляет роль пользователю HORTENSE. Это дает пользователю HORTENSE привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES К таблице DEPARTMENT.

CREATE ROLE MAITRE_D;

COMMIT;

GRANT ALL

ON DEPARTMENT

TO MAITRE_D;

GRANT MAITRE_D TO HORTENSE;

Подключение к базе данных с использованием роли

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

CONNECT <путь-к-базе-данных>

USER <ваше-имя-пользователя>

ROLE <имя-роли>

PASSWORD <ваш-пароль>;

Удаление роли

Если вы удаляете роль, то все привилегии, предоставленные этой роли, отменяются. Чтобы удалить роль MAITRE_D, выполните:

DROP ROLE MAITRE D;

! ! !

ПРИМЕЧАНИЕ. Если вам нужно лишь удалить привилегии, предоставленные пользователю с помощью роли, или удалить привилегии роли, используйте оператор REVOKE (см. разд. "Отмена полномочий").

. ! .

Предоставление прав на предоставление привилегий

Вначале только владелец таблицы или просмотра или пользователь SYSDBA могут предоставлять полномочия к этому объекту другим пользователям. Добавьте WITH GRANT OPTION в конец оператора GRANT для передачи пользователю права предоставлять привилегии вместе с самими привилегиями.

Следующий оператор назначает полномочия SELECT пользователю HPOTTER и дает право HPOTTER предоставлять полномочия SELECT другим:

GRANT SELECT ON DEPARTMENT TO HPOTTER WITH GRANT OPTION;

WITH GRANT OPTION не может назначаться триггерам или процедурам.

Права WITH GRANT OPTION являются кумулятивными, даже если передаются различными пользователями. Например, HPOTTER может получить право предоставлять права SELECT к таблице DEPARTMENT от одного пользователя и INSERT К DEPARTMENT от другого.

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

GRANT INSERT ON DEPARTMENT TO HPOTTER;

Пользователь HPOTTER может выбирать данные и добавлять данные в таблицу DEPARTMENT. Он может предоставлять полномочия SELECT к таблице DEPARTMENT, но не может назначать полномочия INSERT, потому что он не имеет права предоставлять эту привилегию.

Существующие привилегии пользователя могут быть расширены включением права предоставлять привилегии. Для этого нужно выдать второй оператор GRANT для той же привилегии, который будет включать предложение WITH GRANT OPTION.

Для предоставления пользователю HPOTTER права предоставлять полномочия INSERT К таблице DEPARTMENT просто выполните новый оператор:

GRANT INSERT ON DEPARTMENT TO HPOTTER WITH GRANT OPTION;

Подводя итог, скажем, что пользователь может предоставлять привилегии доступа (SELECT, INSERT, UPDATE, DELETE и REFERENCES) К объекту другим пользователям или объектам, если пользователь:

* владеет этим объектом;

* получил такую привилегию к этому объекту вместе с WITH GRANT OPTION;

* получил эту привилегию путем предоставления ему роли, содержащей привилегию вместе с WITH ADMIN OPTION.

SQL допускает операторы GRANT, которые предоставляют пользователю дубликаты полномочий.

Неожиданные эффекты

SQL позволяет.одному и тому же получателю прав получать одни и те же полномочия из различных источников, даже если предоставляемые права уже есть у получателя. Каждый раз, когда один пользователь расширяет у другого пользователя права передавать полномочия, он открывает еще один источник, из которого любой пользователь может получить полномочия. Структура полномочий потенциально может стать пресловутым "птичьим гнездом", из которого очень трудно вытащить фактическое состояние полномочий индивидуального пользователя или объекта.

Предположим, у нас есть два пользователя, SERENA и HPOTTER, с соответствующими привилегиями и правами предоставлять другим полномочия. Оба выдали следующий оператор:

GRAN TINSERT

ON DEPARTMENT

TO BRUNHILDE

WITH GRANT OPTION;

Позднее SERENA отменяет привилегию и право предоставлять полномочия у BRUNHILDE:

REVOKE INSERT

ON DEPARTMENT

FROM BRUNHILDE;

SERENA считает, что BRUNHILDE больше не имеет полномочий INSERT и не может предоставлять другим права к таблице DEPARTMENT. Однако выполненный оператор REVOKE не имеет эффекта, поскольку BRUNHILDE все еще имеет полномочия INSERT и право предоставлять привилегии, полученные от HPOTTER.

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

Если у пользователя была возможность получать права от различных пользователей, существует два возможных решения, оба не очень приятных.

* Найдите каждое право, предоставленное этому пользователю, вместе с тем, кто предоставлял это право, и заставьте всех отменить каждое предоставленное право. Это станет весьма запутанным, если использовались варианты ALL и PUBLIC, потому что отмена более целенаправленного права не отменяет прав, предоставленных через ALL, PUBLIC, роли или группы.

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

Сервер не выдает никаких сообщений для команд REVOKE, независимо от того, была ли она успешна или ошибочна. Это будет тот самый момент вашей первой, неприятности, связанной с полномочиями SQL, когда вы возденете глаза к небесам и начнете размышлять о реальном назначении комитетов по стандартам на этой Земле. Хорошо спроектированная графическая утилита управления правами может сохранить вам рассудок. К счастью, многие программы администрирования осуществляют такую поддержку. Доступно множество инструментов управления полномочиями. (См. приложение 12.)

Более подробную информацию об отмене полномочий см. в следующем разделе.

! ! !

СОВЕТ. Хотя определение пользователей, ролей и назначение привилегий часто откладывается до момента, когда система готова к поставке пользователям, тем не менее создание схемы привилегий и соотнесение ее со списком пользователей нужно запланировать при проектировании системы. Поддержка диаграммы такой схемы является весьма полезным делом как при проектировании и тестировании системы, так и при ее документировании.

. ! .

Отмена полномочий

Оператор REVOKE требуется для удаления полномочий, назначенных операторами GRANT. Согласно стандарту, REVOKE должен каскадом отменить все привилегии, полученные всеми пользователями как результат WITH GRANT OPTION от данного пользователя. Однако вам не следует на это полагаться в Firebird, потому что конфликт правил стандарта при некоторых условиях может привести к логике реализации, отличной от предложенной в стандарте.

Операторы REVOKE могут отменить любую привилегию, которую может назначить оператор GRANT. Только пользователь SYSDBA или пользователь, предоставивший привилегию, могут отменить ее- те же самые или другие привилегии, предоставленные другими пользователями, не отменяются.

Полномочия, предоставленные "в куче", не могут отменяться индивидуально. Это означает:

* привилегия, которую пользователь получил в результате назначения ALL или в качестве роли, может быть отменена только предоставившим эту привилегию, путем отмены ALL или роли соответственно;

* отмена привилегии у пользователя, который получил ее путем PUBLIC или группы UNIX, может быть выполнена предоставившим эту привилегию путем отмены PUBLIC или группы соответственно;