Oracle гранты на схему
Добавил пользователь Евгений Кузнецов Обновлено: 19.09.2024
Вы можете предоставлять и отменять привилегии для различных объектов базы данных в Oracle. Сначала мы рассмотрим, как предоставлять и отменять привилегии для таблиц, а затем, как предоставлять и отменять привилегии функциям и процедурам в Oracle.
Grant Privileges для таблиц
Вы можете предоставить пользователям различные привилегии к таблицам. Эти привилегии могут быть любой комбинацией SELECT, INSERT, UPDATE, DELETE, REFERENCES, ALTER, INDEX, или другие.
Синтаксис
Синтаксис для предоставления привилегий для таблицы в Oracle/PLSQL:
privileges
Привилегии для назначения. Это может быть любое из следующих значений:
| Привилегии | Описание |
|---|---|
| SELECT | Возможность выполнения SELECT на таблице |
| INSERT | Возможность выполнения INSERT на таблице |
| UPDATE | Возможность выполнения UPDATE на таблице |
| DELETE | Возможность выполнения DELETE на таблице |
| REFERENCES | Возможность создавать CONSTRAINT, который ссылается на таблицу. |
| ALTER | Возможность выполнять оператор ALTER TABLE, чтобы изменить описание таблицы. |
| INDEX | Возможность создавать INDEX таблице с помощью оператора CREATE INDEX. |
| ALL | Все привилегии для таблицы |
object
наименование объекта базы данных, которому вы предоставляете привилегии. В случае предоставления привилегий таблице, это должно быть название таблицы.
user
Имя пользователя, которому будет предоставлена эта привилегия.
Пример
Рассмотрим некоторые примеры, предоставления привилегий для таблиц в Oracle.
Например, если вы хотите предоставить SELECT, INSERT, UPDATE и DELETE привилегии на таблицу с наименованием suppliers для user с именем trizor , то нужно выполнить следующие GRANT предложение:
Use the GRANT statement to grant:
Roles to users, roles, and program units. The granted roles can be either user-defined (local or external) or predefined. For a list of predefined roles, refer to Oracle Database Security Guide .
Global roles (created with IDENTIFIED GLOBALLY ) are granted through enterprise roles and cannot be granted using the GRANT statement.
Notes on Authorizing Database Users
You can authorize database users through means other than the database and the GRANT statement.
Many Oracle Database privileges are granted through supplied PL/SQL and Java packages. For information on those privileges, refer to the documentation for the appropriate package.
Some operating systems have facilities that let you grant roles to Oracle Database users with the initialization parameter OS_ROLES . If you choose to grant roles to users through operating system facilities, then you cannot also grant roles to users with the GRANT statement, although you can use the GRANT statement to grant system privileges to users and system privileges and roles to other roles.
Note on Oracle Automatic Storage Management
A user authenticated AS SYSASM can use this statement to grant the system privileges SYSASM , SYSOPER , and SYSDBA to a user in the Oracle ASM password file of the current node.
Note on Editionable Objects
A GRANT operation to grant object privileges on an editionable object actualizes the object in the current edition. See Oracle Database Development Guide for more information about editions and editionable objects.
CREATE USER and CREATE ROLE for definitions of local, global, and external privileges
Oracle Database Security Guide for information about other authorization methods and for information about privileges
REVOKE for information on revoking grants
To grant a system privilege , one of the following conditions must be met:
You must have been granted the GRANT ANY PRIVILEGE system privilege. In this case, if you grant the system privilege to a role, then a user to whom the role has been granted does not have the privilege unless the role is enabled in user's session.
You must have been granted the system privilege with the ADMIN OPTION . In this case, if you grant the system privilege to a role, then a user to whom the role has been granted has the privilege regardless whether the role is enabled in the user's session.
To grant a role to a user or another role , you must have been directly granted the role with the ADMIN OPTION , or you must have been granted the GRANT ANY ROLE system privilege, or you must have created the role.
To grant a role to a program unit in your own schema , you must have been directly granted the role with either the ADMIN OPTION or the DELEGATE OPTION , or you must have been granted the GRANT ANY ROLE system privilege, or you must have created the role.
To grant a role to a program unit in another user's schema , you must be the user SYS and the role must have been created by the schema owner or directly granted to the schema owner.
To grant an object privilege on a user , by specifying the ON USER clause of the on_object_clause , you must be the user on whom the privilege is granted, or you must have been granted the object privilege on that user with the WITH GRANT OPTION , or you must have been granted the GRANT ANY OBJECT PRIVILEGE system privilege. If you can grant an object privilege on a user only because you have the GRANT ANY OBJECT PRIVILEGE , then the GRANTOR column of the *_TAB_PRIVS views displays the user on whom the privilege is granted rather than the user who issued the GRANT statement.
To grant an object privilege on all other types of objects , you must own the object, or the owner of the object must have granted you the object privileges with the WITH GRANT OPTION , or you must have been granted the GRANT ANY OBJECT PRIVILEGE system privilege. If you have the GRANT ANY OBJECT PRIVILEGE , then you can grant the object privilege only if the object owner could have granted the same object privilege. In this case, the GRANTOR column of the *_TAB_PRIVS views displays the object owner rather than the user who issued the GRANT statement.
To specify the CONTAINER clause, you must be connected to a multitenant container database (CDB). To specify CONTAINER = ALL , the current container must be the root.
Use the GRANT statement to grant:
Roles to users, roles, and program units. The granted roles can be either user-defined (local or external) or predefined. For a list of predefined roles, refer to Oracle Database Security Guide .
Global roles (created with IDENTIFIED GLOBALLY ) are granted through enterprise roles and cannot be granted using the GRANT statement.
Notes on Authorizing Database Users
You can authorize database users through means other than the database and the GRANT statement.
Many Oracle Database privileges are granted through supplied PL/SQL and Java packages. For information on those privileges, refer to the documentation for the appropriate package.
Some operating systems have facilities that let you grant roles to Oracle Database users with the initialization parameter OS_ROLES . If you choose to grant roles to users through operating system facilities, then you cannot also grant roles to users with the GRANT statement, although you can use the GRANT statement to grant system privileges to users and system privileges and roles to other roles.
Note on Oracle Automatic Storage Management
A user authenticated AS SYSASM can use this statement to grant the system privileges SYSASM , SYSOPER , and SYSDBA to a user in the Oracle ASM password file of the current node.
Note on Editionable Objects
A GRANT operation to grant object privileges on an editionable object actualizes the object in the current edition. See Oracle Database Development Guide for more information about editions and editionable objects.
CREATE USER and CREATE ROLE for definitions of local, global, and external privileges
Oracle Database Security Guide for information about other authorization methods and for information about privileges
REVOKE for information on revoking grants
To grant a system privilege , one of the following conditions must be met:
You must have been granted the GRANT ANY PRIVILEGE system privilege. In this case, if you grant the system privilege to a role, then a user to whom the role has been granted does not have the privilege unless the role is enabled in user's session.
You must have been granted the system privilege with the ADMIN OPTION . In this case, if you grant the system privilege to a role, then a user to whom the role has been granted has the privilege regardless whether the role is enabled in the user's session.
To grant a role to a user or another role , you must have been directly granted the role with the ADMIN OPTION , or you must have been granted the GRANT ANY ROLE system privilege, or you must have created the role.
To grant a role to a program unit in your own schema , you must have been directly granted the role with either the ADMIN OPTION or the DELEGATE OPTION , or you must have been granted the GRANT ANY ROLE system privilege, or you must have created the role.
To grant a role to a program unit in another user's schema , you must be the user SYS and the role must have been created by the schema owner or directly granted to the schema owner.
To grant an object privilege on a user , by specifying the ON USER clause of the on_object_clause , you must be the user on whom the privilege is granted, or you must have been granted the object privilege on that user with the WITH GRANT OPTION , or you must have been granted the GRANT ANY OBJECT PRIVILEGE system privilege. If you can grant an object privilege on a user only because you have the GRANT ANY OBJECT PRIVILEGE , then the GRANTOR column of the *_TAB_PRIVS views displays the user on whom the privilege is granted rather than the user who issued the GRANT statement.
To grant an object privilege on all other types of objects , you must own the object, or the owner of the object must have granted you the object privileges with the WITH GRANT OPTION , or you must have been granted the GRANT ANY OBJECT PRIVILEGE system privilege. If you have the GRANT ANY OBJECT PRIVILEGE , then you can grant the object privilege only if the object owner could have granted the same object privilege. In this case, the GRANTOR column of the *_TAB_PRIVS views displays the object owner rather than the user who issued the GRANT statement.
To specify the CONTAINER clause, you must be connected to a multitenant container database (CDB). To specify CONTAINER = ALL , the current container must be the root.
Не знаю, чем у вас закончилась история с нашим новым пользователем DUMMY, а у меня он все же остался. Если кто-то из вас создал своего пользователя, то можете воспользоваться своим. А, вот сейчас давайте поговорим о том, как могут взаимодействовать разные схемы БД. И как это все возможно осуществить. Запускайте SQL*Plus и подключайтесь пользователем DUMMY (если вы его все-таки пристрелили, реанимируйте его согласно шагу 101). А теперь, находясь в схеме DUMMY дайте такой запрос:
Неудача "ORA-00942: таблица или представление пользователя не существует"! Говорит само за себя. Теперь попробуем:
В чем же причина? Да просто у пользователя DUMMY нет прав производить чтение из таблицы схемы MILLER! Как его предоставить? Очень просто. Подключаемся к схеме MILLER:
А теперь записываем следующее:
Меняем подключение на DUMMY:
Снова повторяем запрос вот так, чтобы было меньше столбцов:
Получаем в результате:
- system_privilege - предоставляемое системное полномочие.
- role - предоставляемая роль.
- TO - определяет пользователей или роли, которым предоставляются системные полномочия.
- PUBLIC - указывает что, системные полномочия определяемые администратором предоставляются всем пользователям.
- WITH ADMIN OPTION - позволяет получившему системные полномочия или роль предоставлять их в дальнейшем другими пользователям или ролям. Такое решение в частности включает и возможность изменение или удаления роли.
Давайте посмотрим какие системные полномочия могут предоставляться. Основных операций в языке DDL три - это CREATE, ALTER, DROP.
- ALTER DATABASE - Позволяет изменять саму БД.
- ALTER USER - Позволяет изменять пользователя и его параметры (пароль, профиль, роль и т.д.)
- ALTER PROFILE - Позволяет изменять профили.
- ALTER TABLESPACE - Позволяет изменять табличные пространства.
- ALTER ANY PROCEDURE - Разрешает изменение любой хранимой функции процедуры или пакета в любой схеме.
- ALTER ANY ROLE - Разрешает изменение любой роли БД.
- ALTER ANY SEQUENCE - Разрешает изменение любой последовательности в БД.
- ALTER ANY TABLE - Разрешает изменение любой таблицы или вида в схеме БД.
- ALTER ANY TRIGGER - Позволяет разрешать, запрещать компилировать любой триггер в любой схеме БД.
- ALTER ANY INDEX - Разрешает изменение любого индекса в любой схеме.
Группа CREATE:
Позволяет создавать в любой схеме соответствующий объект:
Позволяет создавать в конкретной схеме соответствующий объект:
Удаление объектов в любой схеме, а так же очистка таблиц:
Удаление объектов в схеме:
И еще полезные системные привилегии:
Вот далеко не полный список системных привилегий, которые предоставляются оператором GRANT. Для начала я думаю хватит. А дальше все зависит от вас. Давайте теперь рассмотрим предоставление объектных привилегий. Здесь все выглядит вот так:
object_privilege - предоставляемая привилегия - одна из:
COLUMN - определяет столбец таблицы или вида, на который распространяется предоставляемая привилегия.
ON - определяет объект (таблицу, вид, и т.д.)
TO - указывает кому предоставляется привилегия.
WITH ADMIN OPTION - позволяет имеющему эту привилегию предоставлять их в дальнейшем другими пользователям или ролям.
Как с работать с этим типом мы с вами уже пробовали в начале этого шага! Можете, например добавить еще что-нибудь к вышеизложенному примеру. И наконец, давайте рассмотрим как привилегии изымаются или удаляются. Для этого необходимо применять оператор REVOKE. Его синтаксис аналогичен первым двум операторам за небольшим исключением:
Например, чтобы изъять привилегию на выборку из таблицы SALESREPS для схемы DUMMY введите следующее находясь в схеме MILLER:
Получим примерно следующее:
Вот таким образом применяя операторы GRANT и REVOKE, можно строить взаимоотношение схем и строить политику доступа к объектам БД. Попробуйте создать в новом пользователе несколько объектов и разрешить обращаться к ним из схемы MILLER. Если что не получится пишите!
В базе данных Oracle схема (schema) определяется как коллекция логических структур данных, или объектов схемы, хотя в основном используется в качестве синонима пользователя базы данных (в частности, владельца приложения), который владеет схемой, относящейся к определенному приложению. Таким образом, схема accounting (бухгалтерия) внутри базы данных компании должна владеть всеми таблицами и кодом, относящимся к бухгалтерскому отделу. В дополнение к таблицам, схема включает в себя и другие объекты базы, такие как процедуры и функции PL/SQL, представления, последовательности, синонимы и кластеры. Подобное логическое отделение объектов внутри базы данных позволяет существенно облегчить задачу управления и защиты базы данных Oracle Database.
Хотя администратор баз данных может использовать оператор CREATE SCHEMA для заполнения схемы объектами базы данных, наподобие таблиц и представлений, гораздо чаще владелец приложения создает объекты базы, и его называют владельцем схемы . Пользователь, который создает объекты, владеет такими объектами, как таблицы, представления, процедуры, функции и триггеры. Владелец объекта должен явно выдать права доступа другим пользователям, наподобие прав на SELECT или UPDATE, чтобы пользователи могли работать с этими объектами.
Определяемые пользователем типы объектов
Oracle Database 11g и 12c — объектно-реляционная база данных, и как таковая, позволяет пользователям определять несколько типов объектов данных, которых нет среди стандартных реляционных типов данных. Эти определяемые пользователем объекты включают перечисленные ниже.
- Объектные типы. Эти сложные типы являются абстракциями сущностей реального мира.
- Типы массивов. Эти типы используются для создания упорядоченных множеств элементов данных одного и того же типа.
- Табличные типы. Эти типы используются для создания неупорядоченных наборов элементов данных одного и того же типа.
- Схемы XML. Это новый объектный тип, используемый для создания типов и элементов хранения документов XML на основе схемы XML.
В приложении приведены примеры создания различного рода пользовательских объектных типов.
Вдобавок, владелец схемы может также создавать синонимы, которые служат псевдонимами различных объектов для других пользователей базы. Синонимы, которые будут описаны далее в моих статьях, служат множеству целей, включая маскировку принадлежности объектов данных и упрощение операторов SQL для пользователей, за счет исключения необходимости для них специфицировать имя владельца схемы при каждом обращении к объекту данных, не принадлежащему им.
Существуют два основных способа создания схемы в базе данных Oracle. Более распространенный способ состоит в подключении от имени владельца схемы и создании всех таблиц, индексов и прочих объектов, которые планируется включить в схему. Поскольку все объекты создаются владельцем схемы, они автоматически становятся частью этой схемы.
Второй способ создания схемы предусматривает ее явное создание с помощью оператора CREATE SCHEMA. Этот оператор позволяет создать множество таблиц и представлений, а также выдать пользователям привилегии доступа к ним, и все это в единственном операторе SQL.
Читайте также: