Вопрос

Я пытался предоставить CONNECT пользователю через роль:

CREATE ROLE my_role IDENTIFIED BY "passwd";
GRANT CONNECT TO my_role;

CREATE USER my_user IDENTIFIED BY "passwd";
GRANT my_role TO my_user;

Когда я пробую это в 10 г это работает нормально, в то время как в 11g вход в систему отклонен:

ORA-01045:user MY_USER lacks CREATE SESSION privilege; logon denied

Предоставление CREATE SESSION для роли это не имеет значения.
Я могу войти в систему только после прямого предоставления CONNECT (или CREATE SESSION) для пользователя.

Изменил ли Oracle это поведение или я делаю что-то не так?

Это было полезно?

Решение

Я думаю, вам могла сойти с рук "функция" безопасности в 10g.То, как я прочитал справочник по SQL и руководство по безопасности для 11g, указывает на то, что роли с поддержкой паролей требуют использования SET ROLE my_role IDENTIFIED BY passwd прежде чем какие-либо права, предоставленные этой ролью, вступят в силу.

Ты не можешь CREATE SESSION пока у вас не будет роли, а вы не можете получить эту роль, пока не выдадите SET ROLE.

Улов-22.

Другие советы

База знаний Oracle [ID 745407.1] объясняет это.

Предложение ПО УМОЛЧАНИЮ в:

изменять роли пользователей по умолчанию ;определяет роли, предоставленные пользователю по умолчанию при входе в систему.Это предложение может содержать только роли, которые были предоставлены непосредственно пользователю с помощью инструкции GRANT, или роли, созданные пользователем с привилегией CREATE ROLE.Вы не можете использовать предложение РОЛИ ПО УМОЛЧАНИЮ для включения:

  1. Роли, не предоставленные пользователю

  2. Роли, предоставленные через другие роли

  3. Роли, управляемые внешней службой (такой как операционная система) или Oracle Internet Directory

  4. Роли, прошедшие проверку подлинности по паролю.

  5. Роли, которые реализованы как роли защищенного приложения.

Для ролей, прошедших проверку подлинности паролем, это изменение было внесено в версиях 10.2.0.5 и 11.1.0.7.Что касается ролей защищенных приложений, изменение было внесено в выпуски Oracle 10.2.0.4 и 11.1.0.7 Эти изменения будут применяться ко всем будущим выпускам.Вышеупомянутые ограничения будут введены в будущей документации.

Можно легко превратить роли с поддержкой пароля в стандартные роли, запустив скрипт, полученный из:

выберите 'изменить роль'||роль||'не идентифицирована;' из dba_roles, где password_required='YES' и роль не включена (выберите роль из dba_application_roles);

Активация ролей по умолчанию (предоставляемых пользователю по умолчанию), которые также защищены паролем, изменена в Oracle 10g версии 10.2.0.5 (по крайней мере, для нашей копии).В выпуске 10.2.0.5 роль, защищенная паролем, больше не будет активироваться по умолчанию.Он должен был быть специально включен с соответствующим паролем.

Насколько мы могли судить, это не было задокументировано.Но когда наши системы были обновлены с 10.2.0.4 до 10.2.0.5, это изменение нарушило работу нескольких наших систем, и нам пришлось создавать параллельные незащищенные роли для наших функциональных учетных записей, у которых не было никакого механизма для активации ролей по умолчанию.По сути, мы создали old_role_batch без пароля как копию old_role, которая была защищена паролем.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top