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

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

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.)

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

! ! !

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

. ! .