Опция grant не существует oracle

Обновлено: 07.07.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 предложение:

Я нахожусь в Oracle 11g, и я понимаю проблему стороннего гранта.

Но, учитывая, что пользователь1 создает представление "view1" как Select 'foo' из dual.

Затем я предоставляю Select on view1 для user2, и я получаю эту ошибку.

Но обратите внимание, что "двойное" в представлении не квалифицируется как sys.dual, оно просто двойственное. Я бы подумал с синонимом public.dual, что фактическое "двойное" использовалось бы public.dual, а не sys.dual, поэтому никакой сторонний вопрос не должен существовать, потому что он публичный.

И если sys.dual - это тот, который Oracle предполагает в этом представлении, можно подумать, что использование двойного представления является общим в представлениях, а также предоставление привилегий другим пользователям в отношении взглядов других пользователей - не было бы тысяч пользователи должны сообщать об этой проблеме?

После консультаций с нашими базами данных проблема - это Oracle "Feature" в 11.2.0.4:

TL; DR verison: Начиная с версии 11.0.4, если ваш вид использует Двойной, то вы не можете предоставить этот вид ничего, кроме SELECT.

Почему мы хотим предоставить представление больше, чем Select? В нашем случае поставщик приложений упаковал свои обновления таким образом, что часть базы данных обновлений автоматически записывала полный CRUD-грант в главную схему приложения на каждом новом объекте, и это включало представления, потому что было просто проще script сюда. Все это работало нормально до 11.0.4, когда Oracle сказал/принудительно: "Эй, вы не можете этого сделать".

Oracle Database - Enterprise Edition - версия 11.2.0.4 - 11.2.0.4 [выпуск 11.2] Информация в этом документе относится к любой платформе. СИМПТОМЫ После обновления с 11.2.0.3 по 11.2.0.4 вы сталкиваетесь со следующей ошибкой при выполнении инструкции "create or replace view": ORA-01720: опция гранта не существует Представления были созданы до обновления и "CREATE OR REPLACE VIEW" отлично работали. ПРИЧИНА Наблюдаемое поведение является правильным. Вы получите эту ошибку ORA-1720 при ЗАМЕНЕ просмотра, которое выбирает из некоторых других пользовательских таблиц, и выполняются оба следующих условия:

вы уже предоставили избранные или другие привилегии для VIEW другому пользователю
У владельца представления нет опции GRANT для выбранных таблиц (или владелец представления может иметь некоторую привилегию с вариантом гранта, но не другие) Развитие объяснило это следующим образом:

Код был изменен в 11.2.0.4, чтобы создать поведение представления аналогично предоставлению. Если вы попытаетесь сделать GRANT на существующем представлении, а владелец представления не имеет опции гранта, то ожидаемый результат ORA-1720 (даже в 11.2.0.3). В 11.2.0.4 мы просто сделали CREATE VIEW совместимым с поведением GRANT, т.е. Если существует несовместимый грант, то новое определение представления не должно быть разрешено (даже с FORCE). Другими словами, мы не позволяем несовместимым грантам сосуществовать с определением вида, и поэтому необходимо выбросить ошибку. Поведение в версии 11.2.0.3 (и ранее) было неправильным; новое поведение в 11.2.0.4 является преднамеренным и правильным. РЕШЕНИЕ Чтобы избежать этой проблемы, вы можете выполнить одно из следующих действий:

Удалите все гранты в представлении перед ЗАМЕНЕНИЕМ представления. Это обеспечит отсутствие несовместимых грантов.
Снимите и заново создайте представление. Удаление представления автоматически удалит все гранты.

ЛИТЕРАТУРЫ BUG: 17994036 - ОБНОВЛЕНИЕ ДОКЛАДОВ ДО 11.2.0.4 СОЗДАТЬ ИЛИ ЗАМЕНИТЬ НЕИСПРАВНОСТИ С ORA-01720 BUG: 18024486 - ORA-1720 ПРИ СОЗДАНИИ ВИДА ПОСЛЕ ОБНОВЛЕНИЯ от 11.2.0.3.0 до 11.2.0.4.0

Я нахожусь на Oracle 11g, и я действительно понимаю проблему гранта третьей стороны.

Но, учитывая, что у пользователя user1 создание представления "view1" как выбрать 'foo' от двойной.

Затем я предоставляю Select on view1 пользователю user2 и получаю эту ошибку.

Но обратите внимание, что "dual" в представлении не квалифицируется как sys.dual, это просто двойственно. Я бы подумал с синонимом public.dual, что фактический "dual" будет использоваться public.dual, а не sys.dual, так что никакой сторонней проблемы не должно существовать, потому что она публична.

И если sys.dual-это то, что Oracle предполагает в этом представлении, можно было бы подумать, что, учитывая, что использование dual распространено в представлениях, и что предоставление привилегий на представления другим пользователям также распространено-разве тысячи пользователей не сообщали бы об этой проблеме?

2 ответа

В моей базе данных oracle есть пользователь (скажем, SWEET). Внутри схемы SWEET у меня есть таблица под названием AUTO_PARTS. Теперь я создал нового пользователя (SWEET_CV) и создал представление в таблице AUTO_PARTS SWEET. CREATE SCHEMA AUTHORIZATION SWEET_CV CREATE VIEW.

где-то по пути что-то идет не так, и я не могу понять почему. Если об этом уже просили извинения. У меня есть 3 схемы в моей базе данных: COLLDESK LOCAL_IT Гербен COLLDESK - это наша основная схема, LOCAL_IT-это место, где мы делаем нашу локальную разработку, а GERBEN-это конечный пользователь.

После консультации с нашими базами данных проблема заключается в Oracle "Feature" в 11.2.0.4:

TL;ДОКТОР верисон: Начиная с v 11.0.4, если в вашем представлении используется Dual, вы не можете предоставить этому представлению ничего, кроме SELECT.

Почему мы хотим предоставить представление больше, чем Выбрать? В нашем случае поставщик приложений упаковал свои обновления таким образом, что часть обновлений базы данных автоматически создавала сценарии полных CRUD для главной схемы приложения для каждого нового объекта, и это включало представления, потому что так было просто проще писать сценарии. Все это прекрасно работало до 11.0.4, когда Oracle сказал/принудил "Hey, you can't do that".

Oracle Database - Enterprise Edition - Версия с 11.2.0.4 по 11.2.0.4 [Выпуск 11.2] Информация, содержащаяся в этом документе, применима к любой платформе. СИМПТОМЫ После обновления с 11.2.0.3 до 11.2.0.4 при выполнении инструкции "create or replace view" возникает следующая ошибка: ORA-01720: опция предоставления не существует Представления были созданы до обновления, и "CREATE OR REPLACE VIEW" работал нормально. ПРИЧИНА Наблюдаемое поведение является правильным. Вы получите эту ошибку ORA-1720, когда REPLACING представление, которое выбирает из таблиц некоторых других пользователей, и оба из следующих условий верны:

вы уже предоставили select или другие привилегии на VIEW какому-либо другому пользователю
владелец представления не имеет опции GRANT в таблицах, из которых выбирается (или владелец представления может иметь некоторые привилегии с опцией grant, но не другие) Развитие объяснило это следующим образом:

Код был изменен в 11.2.0.4, чтобы поведение create view было похоже на grant. Если вы попытаетесь сделать GRANT в существующем представлении, а у владельца представления нет опции предоставления, то ORA-1720-это ожидаемый результат (даже в 11.2.0.3). В 11.2.0.4 мы просто сделали CREATE VIEW совместимым с поведением GRANT, т. Е. Если существует несовместимый грант, то новое определение представления не должно быть разрешено (даже с FORCE). Другими словами, мы не позволяем несовместимым грантам сосуществовать с определением представления, и поэтому должна быть выдана ошибка. Поведение в выпуске 11.2.0.3 (и ранее) было неправильным; новое поведение в 11.2.0.4 является преднамеренным и правильным. РЕШЕНИЕ Чтобы избежать этой проблемы, вы можете выполнить одно из следующих действий:

Удалите все разрешения в представлении перед REPLACING представлением. Это обеспечит отсутствие несовместимых грантов.
Отбросьте и воссоздайте представление. Удаление представления автоматически удалит все гранты.

REFERENCES BUG:17994036 - ПОСЛЕ ОБНОВЛЕНИЯ ДО 11.2.0.4 СОЗДАТЬ ИЛИ ЗАМЕНИТЬ НЕ УДАЕТСЯ С ПОМОЩЬЮ ORA-01720 BUG:18024486 - ORA-1720 ПРИ СОЗДАНИИ ПРЕДСТАВЛЕНИЯ ПОСЛЕ ОБНОВЛЕНИЯ С 11.2.0.3.0 TO 11.2.0.4.0

У меня есть пользователь с несколькими таблицами, и я предоставил привилегии трем из них другому пользователю. Теперь мне нужно создать view и предоставить select другому пользователю, например: Пользователь А GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE_A TO USER_B WITH GRANT OPTION; GRANT.

Я пытаюсь создать нового пользователя Oracle, которого он может выбрать только из таблиц ( ReadOnly ) SO я должен был выполнить следующие строки на схеме SYS : (например, 7502438 ) 1-Создать пользователя CREATE USER my_user IDENTIFIED BY my_password DEFAULT TABLESPACE users TEMPORARY TABLESPACE.

С помощью sys (как sysdba ) пользователь базы данных предоставляет необходимые привилегии, а затем пытается воссоздать представление с помощью пользователя базы данных sys (как sysdba ). Это было полезно для меня.

С уважением, Ваза Тусевский

Похожие вопросы:

Используя SQLDeveloper 4.0.1.14 для создания сценария экспорта (отдельные файлы & drops проверены), он сгенерировал мне эти 4 строки среди других в DROP.sql : DROP SYNONYM PUBLIC.DUAL; DROP.

ORA-02289: последовательность не существует, ошибка в hibernbate

У меня есть проблема в моей среде Oracle 11.2.0.4.0, которая ставит меня в тупик. У меня есть представление WORKING, COMPILED, из которого я могу выбирать данные, но я не могу изменить его, не.

Как я могу проверить, есть ли у пользователя опция SELECT WITH GRANT в Teradata? Я знаю, как получить список разрешений с помощью DBC.ROLEMEMBERS и DBC.ALLROLERIGHTS, просто не вижу способа.

Я пытаюсь импортировать дамп DB , созданный с помощью команды EXPDP. Ниже приводится команда, которую я использовал для импорта. impdp vnp/vnp directory=MY_DATA_PUMP_DIR.

Не знаю, чем у вас закончилась история с нашим новым пользователем 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 11g, и я понимаю проблему стороннего гранта.

Но, учитывая, что у пользователя user1, создающего представление "view1", выберите "foo" из двойного.

Затем я предоставляю Select on view1 пользователю user2 и получаю эту ошибку.

И если sys.dual - это то, что Oracle предполагает в этом представлении, можно подумать, что, учитывая использование двойного представления, распространено в представлениях, и что предоставление привилегий для представлений другим пользователям также распространено - разве тысячи пользователей не будут сообщать Эта проблема?

После консультации с нашей базой данных проблема связана с "функцией" Oracle в 11.2.0.4:

Версия TL; DR: Начиная с версии 11.0.4, если ваше представление использует Dual, вы не можете предоставить этому представлению ничего, кроме SELECT.

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

Код был изменен в 11.2.0.4, поэтому поведение создания представления аналогично предоставлению. Если вы пытаетесь сделать GRANT для существующего представления, а у владельца представления нет опции предоставления, то ожидаемым результатом будет ORA-1720 (даже в 11.2.0.3). В 11.2.0.4 мы просто сделали CREATE VIEW совместимым с поведением GRANT, т.е. если существует несовместимый грант, то определение нового представления не должно быть разрешено (даже с FORCE). Другими словами, мы не позволяем несовместимым грантам сосуществовать с определением представления, поэтому должна быть выдана ошибка. Поведение в версии 11.2.0.3 (и ранее) было некорректным; новое поведение в 11.2.0.4 является преднамеренным и правильным. РЕШЕНИЕ Чтобы избежать этой проблемы, вы можете сделать одно из следующих действий:

Удалите все гранты в представлении перед ЗАМЕНОМ представления. Это гарантирует отсутствие несовместимых грантов.
Отбросьте и воссоздайте вид. Удаление представления автоматически удалит все гранты.

ССЫЛКИ НА ОШИБКУ: 17994036 - ОБНОВЛЕНИЕ ПОСЛЕ ОБНОВЛЕНИЯ ДО 11.2.0.4 СОЗДАТЬ ИЛИ ЗАМЕНИТЬ СБОЙ С ОШИБКОЙ ORA-01720: 18024486 - ORA-1720 ПРИ СОЗДАНИИ ВИДА ПОСЛЕ ОБНОВЛЕНИЯ С 11.2.0.3.0 ДО 11.2.0.4.0

Это нас тоже задело, но по гораздо более мягкой причине, что мы пытались добавить грант DEBUG в представление.

С помощью sys (как sysdba) пользователь базы данных предоставит необходимые привилегии, а после этого попробуйте воссоздать представление с помощью пользователя базы данных sys (как sysdba). Это было полезно для меня.

Читайте также: