Разрешение и запрещение ролей

. Пользователь, которому предоставлена роль, не всегда имеет доступ к ее привилегиям. В ORACLE приложения могут разрешать и запрещать роли для любого пользователя. После того как приложение разрешает роль для пользователя, ему становятся доступны ее привилегии. И, соответственно, когда приложение запрещает роль для пользователя, он более не имеет доступа к ее привилегиям. Возможность динамически управлять набором привилегий позволяет приложениям обеспечивать постоянную корректность наборов привилегий пользователей во время работы с данным приложением. Например, когда пользователь запускает приложение по вводу заказов, с помощью SQL-команды SET ROLE это приложение разрешает ему применять для работы роль ORDER_ENTRY (см. пример). Когда пользователь завершает свою работу, приложение запрещает для него эту роль, и он не может применять привилегии приложения по вводу заказов во время работы с другим приложением.

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

Рисунок Синтаксическая диаграмма инструкции GRANT

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

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

Вместо того чтобы давать привилегии по отдельности каждому пользователю базы данных, можно с помощью ключевого слова PUBLIC предоставить их сразу всем пользователям, имеющим право работать с базой данных. Такая инструкция GRANT дает привилегии всем нынешним и будущим пользователям базы данных, а не только тем, кто имеет право работать с базой данных в настоящее время. Это устраняет необходимость явно предоставлять привилегии новым пользователям при их появлении.

Передача привилегий (предложение WITH GRANT OPTION). Если пользователь создает в базе данных объект и, тем самым становитесь его владельцем, то только он может предоставлять привилегии на этот объект. Когда он предоставляет привилегии другим пользователям, они могут пользоваться объектом, но не могут передавать эти привилегии кому-то еще. Таким образом, владелец объекта сохраняет строгий контроль над тем, кому какие формы доступа к объекту разрешены.

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

grant select on orders to secretary with grant option;

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

Теперь secretary может выполнить следующую инструкцию GRANT:

grant select on orders to somebody;

Такая инструкция позволяет somebody извлекать данные из представления orders. Так как secretary не включил в свою инструкцию GRANT предложение WITH GRANT OPTION, цепочка заканчивается на somebody; он может извлекать данные из представления orders, но не может давать право на доступ к нему другому пользователю.

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

Посредством инструкции REVOKE можно отобрать только те привилегии, которые вы предоставили ранее некоторому пользователю. У него могут быть также привилегии, предоставленные другими пользователями; ваша инструкция REVOKE не влияет на эти привилегии.

Рисунок Синтаксическая диаграмма инструкции REVOKE

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

Инструкция REVOKE и права предоставления привилегий. Когда вы даете кому-нибудь привилегии с правом последующего предоставления, а затем отменяете эти привилегии, то в большинстве СУБД автоматически отменяются все привилегии, которые являются производными от исходных. Рассмотрим еще раз цепочку привилегий: владелец → secretary → somebody. Если теперь владелец отменит привилегии secretary на представление orders, то привилегии somebody; также будут автоматически отменены.

Ситуация становится более сложной, если привилегии предоставляются двумя или более пользователями, один из которых впоследствии отменяет привилегии. Рассмотрим пример (см. рисунок). Он представляет собой предыдущий пример в слегка измененном виде. Здесь secretary получает привилегию SELECT с правом предоставления, как от владельца, так и от anybody, а затем дает привилегии somebody. На этот раз, когда владелец отменяет привилегии secretary, остаются привилегии, предоставленные anybody. Привилегии somebody также остаются, поскольку они могут происходить от привилегий anybody.

Рисунок Отмена привилегий, предоставленных двумя пользователями

Рассмотрим другой вариант этой цепочки привилегий, в котором изменен порядок событий (рисунок. Здесь secretary получает привилегию с правом предоставления от владельца, дает эту привилегию somebody и после этого получает привилегию с правом предоставления от anybody. Когда на этот раз владелец отменяет привилегии secretary, результат будет другим и может отличаться на разных СУБД. Как и в случае, изображенном на рисунке, у secretary останется привилегия SELECT на представление orders, предоставленная anybody. Но somebody автоматически потеряет привилегию SELECT. Произойдет это потому, что привилегия somebody явно происходит от привилегии, данной владельцем и только что отмененной. Она не может быть производной от привилегии, предоставленной secretary пользователем anybody, так как эта привилегия отсутствовала в тот момент, когда somebody давал привилегию somebody.

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

Рисунок Отмена привилегий, предоставленных в другой последовательности

Дата добавления: 2014-01-04