Просмотр ролей пользователей Oracle

Обновлено: 30.06.2024

Вопрос: я хочу отобразить все привилегии пользователя Oracle, включая прямые гранты и ролевые гранты. Как отобразить все, что было предоставлено пользователю?

Ответ. Чтобы получить полные сценарии, загрузите коллекцию сценариев Oracle . Существует множество представлений, содержащих привилегии пользователя:

dba_sys_privs
dba_tab_privs
dba_role_privs
табличные_привилегии

Этот запрос показывает все привилегии, предоставленные на уровне таблицы для пользователя с именем 'MYUSER':

выберите
владельца,
имя_таблицы,
select_priv,
insert_priv,
delete_priv,
update_priv,
references_priv,
alter_priv,
index_priv,
от
table_привилегий,
где
получатель = 'USER_A'
по
владельцу,
table_name;

Этот запрос показывает все привилегии роли для пользователя:

выбрать отдельного
владельца,
имя_таблицы,
привилегию,
из
dba_role_privs rp,
role_tab_privs rtp,
где
rp .granted_role = rtp.role
и
rp.grantee = 'MYUSER'
по заказу
владельца,
table_name;

В следующем примере будут показаны все системные и ролевые привилегии для пользователя с именем MYUSER:

выберите
привилегию
из
sys.dba_sys_privs,
где
grantee = 'MYUSER'
объединение
выберите
привилегию
от
dba_role_privs rp
присоединиться
role_sys_privs rsp
на (rp.granted_role = rsp.role)
где rp.grantee = 'MYUER'
/>упорядочить по 1;

Обучение Oracle от Дона Берлесона

Лучшие на сайте «Учебные курсы Oracle» находятся на расстоянии одного телефонного звонка! Вы можете пройти индивидуальное обучение Oracle от Дональда Берлесона прямо в своем магазине!

Бурлесон — американская команда

Примечание. Эта документация по Oracle была создана в качестве справочника по поддержке и обучению Oracle для использования нашими специалистами-консультантами по настройке производительности администраторов баз данных. Не стесняйтесь задавать вопросы на нашем форуме Oracle.

Проверьте опыт! Любой, кто рассматривает возможность использования услуг эксперта службы поддержки Oracle, должен самостоятельно проверить свои полномочия и опыт, а не полагаться на рекламу и самопровозглашенный опыт. Все законные эксперты Oracle публикуют свои квалификации Oracle.

Ошибки? Технология Oracle меняется, и мы стараемся обновлять нашу информацию о поддержке BC Oracle. Если вы обнаружите ошибку или у вас есть предложение по улучшению нашего контента, мы будем признательны за ваш отзыв. Просто электронная почта:

и укажите URL-адрес страницы.

Burleson Consulting

Оракул поддержки баз данных

Я использую Linux, Oracle10g. Я создал одного пользователя с именем test. и предоставил разрешение на создание сеанса и выбор любого словаря тому же пользователю.

Я также предоставил роли sysdba и sysoper тем же пользователям.

Теперь я хочу отобразить все привилегии и роли, предоставленные пользователю. Я нашел следующий запрос, но он показывает только создание сеанса и выбор привилегий словаря.

пожалуйста, помогите решить проблему.

9 ответов 9

В дополнение к ответу VAV, первый был наиболее полезен в моей среде

Проверьте таблицы USER_SYS_PRIVS, USER_TAB_PRIVS, USER_ROLE_PRIVS с помощью этих операторов выбора

Другими словами, выполните SELECT * FROM этих таблиц. Не будем лениться. Я расстраиваюсь, когда не вижу кода. Не все могут читать ваши мысли на предмет точного синтаксиса, а ссылки на документацию могут перемещаться.

если вы, как и я, ищете роли, предоставленные «всему, что есть в базе данных», USER_ROLE_PRIVS вам не подойдет, потому что: «USER_ROLE_PRIVS описывает роли, предоставленные текущему пользователю», как говорится в документации Oracle. Вместо этого вам следует искать информацию в представлении DBA_ROLE_PRIVS. Почему? Потому что: "DBA_ROLE_PRIVS описывает роли, предоставленные всем пользователям и роли в базе данных"

Ни один из других ответов мне не помог, поэтому я написал собственное решение:

Начиная с Oracle 11g.

Замените USER на желаемое имя пользователя

Предоставленные роли:

Права, предоставляемые непосредственно пользователю:

Права, предоставленные роли, предоставленной пользователю:

Предоставленные системные права:

Если вы хотите найти пользователя, под которым вы в данный момент подключены, вы можете заменить DBA в имени таблицы на USER и удалить предложение WHERE.

В завершение еще одно — системные привилегии, предоставленные роли, предоставленной пользователю: SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE IN (SELECT grant_role FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'DWMGR');

Сочетайте предыдущие предложения для определения ваших личных разрешений (например, разрешений «ПОЛЬЗОВАТЕЛЬ»), а затем используйте следующее:

ЕСЛИ привилегии даны пользователю через некоторые роли, то можно использовать SQL ниже

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

всегда делайте SQL повторно используемым: -:)

Проверяет только группу ROLES для данной роли. Если мы говорим о повторном использовании, он должен 1) перебирать группу USER и выдавать * из USER_ROLE_PRIVS , USER_TAB_PRIVS и USER_SYS_PRIVS для данного пользователя, затем 2) давать роли для данного пользователя, который вводится (например, в ShamrockCS ' отвечать). Я думаю, что, учитывая вопрос OP, мы хотим знать свойства данного пользователя, а не пользователей с заданной ролью.

Единственный видимый результат, который я смог понять, это сначала соединиться с пользователем, которому я хотел получить права, а затем со следующим запросом:

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

В этом кратком руководстве мы рассмотрим как базовый метод запросов SQL, так и расширенный метод сценариев, поэтому у вас не возникнет проблем независимо от сложности вашей настройки.

Запрос представлений привилегий DBA/USER

Администратор базы данных (DBA) для Oracle может просто выполнить запрос для просмотра строк в DBA_SYS_PRIVS , DBA_TAB_PRIVS и DBA_ROLE_PRIVS для получения информации о привилегиях пользователя, связанных с системой , таблицами и ролями соответственно.

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

Представление DBA_SYS_PRIVS содержит три столбца данных:

GRANTEE – это имя, роль или пользователь, которому была назначена привилегия.
ПРИВИЛЕГИЯ — это назначенная привилегия.
ADMIN_OPTION указывает, включает ли предоставленная привилегия параметр ADMIN.

Чтобы определить, какие пользователи имеют прямой доступ к таблице, мы будем использовать представление DBA_TAB_PRIVS:

GRANTEE – это имя пользователя с предоставленным доступом.
ИМЯ_ТАБЛИЦЫ – это имя объекта (таблицы, индекса, последовательности и т. д.).
PRIVILEGE — это привилегия, назначенная GRANTEE для связанного объекта.

Наконец, запрос к представлению DBA_ROLE_PRIVS содержит большую часть той же информации, но применимой вместо этого к ролям, где столбец GRANTED_ROLE указывает рассматриваемую роль:

Запрос прав текущего пользователя

Если доступ администратора базы данных невозможен или необходим, можно также немного изменить приведенные выше запросы, чтобы просмотреть привилегии только для текущего пользователя.

Это делается путем альтернативного запроса версий USER_ указанных выше представлений DBA_. Таким образом, вместо просмотра DBA_SYS_PRIVS мы запросим USER_SYS_PRIVS, например:

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

Расширенный скрипт для поиска всех привилегий

Хотя описанные выше методы будут работать для базовых конфигураций системы, в Oracle все становится не так, когда существует много ролей, которые, в свою очередь, предоставляют ролевые привилегии другим ролям, и так далее по кроличьей норе. Поскольку в представлениях привилегий DBA_ и USER_ отображаются только GRANTEES с непосредственно назначенным доступом, зачастую привилегии, унаследованные через другие роли, не будут сразу отображаться.

Чтобы решить эту проблему, рекомендуется использовать расширенный сценарий, такой как доверенная работа Пита Финнигана и его сценарий find_all_privs.sql. Вы также можете выбрать модифицированную версию от Дэвида Артура, find_all_privs2.sql .

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

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

Управление пользователями Oracle

Каждая база данных Oracle имеет список действительных пользователей базы данных.Чтобы получить доступ к базе данных, пользователь должен запустить приложение базы данных и подключиться к экземпляру базы данных, используя допустимое имя пользователя, определенное в базе данных. В этом разделе объясняется, как управлять пользователями базы данных, и он содержит следующие темы:

Справочник Oracle Database SQL для получения дополнительной информации об операторах SQL, используемых для управления пользователями

Создание пользователей

Вы создаете пользователя базы данных с помощью инструкции CREATE USER. Чтобы создать пользователя, вы должны иметь системную привилегию CREATE USER. Поскольку это мощная привилегия, администратор баз данных или безопасности обычно является единственным пользователем, имеющим системную привилегию CREATE USER.

В примере 11-1 создается пользователь и указывается пароль пользователя, табличное пространство по умолчанию, временное табличное пространство, в котором создаются временные сегменты, квоты табличного пространства и профиль.

Пример 11-1 Создание пользователя и предоставление системного права на создание сеанса

Вновь созданный пользователь не может подключиться к базе данных, пока ему не будет предоставлена системная привилегия CREATE SESSION.

Как администратор, вы должны создавать свои собственные роли и назначать только те привилегии, которые необходимы. Например, многие пользователи, которым ранее была предоставлена привилегия CONNECT, не нуждались в дополнительных привилегиях, которые предоставляла CONNECT. Вместо этого на самом деле требовалось только CREATE SESSION, и фактически это единственная привилегия, которую в настоящее время сохраняет CONNECT.

Создание собственных ролей дает организации детальный контроль над привилегиями, которые она назначает, и защищает ее в случае изменения Oracle ролей, которые она определяет. Например, роли CONNECT и RESOURCE будут объявлены устаревшими в будущих версиях Oracle.

Этот раздел относится к предыдущему примеру, поскольку в нем обсуждаются следующие аспекты создания пользователя:

Предоставление системных привилегий и ролей на стр. 25-11

Указание имени

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

Настройка аутентификации пользователя

В примере 11-1 новый пользователь должен быть аутентифицирован с использованием базы данных. В этом случае подключающийся пользователь должен указать правильный пароль для базы данных для успешного подключения.

Выбор и указание метода аутентификации пользователя обсуждается в разделе "Методы аутентификации пользователя".

Назначение табличного пространства по умолчанию

У каждого пользователя должно быть табличное пространство по умолчанию. Когда пользователь создает объект схемы и не указывает табличного пространства для него, Oracle Database сохраняет объект в пользовательском табличном пространстве по умолчанию.

Настройкой по умолчанию для табличных пространств по умолчанию для всех пользователей является табличное пространство SYSTEM. Если пользователь не создает объекты и не имеет на это прав, то этот параметр по умолчанию подходит. Однако, если пользователь может создать объект любого типа, вам следует специально назначить пользователю табличное пространство по умолчанию. Использование табличного пространства, отличного от SYSTEM, снижает конкуренцию между объектами словаря данных и пользовательскими объектами за одни и те же файлы данных. Как правило, не рекомендуется хранить пользовательские данные в табличном пространстве SYSTEM.

Во время создания базы данных вы можете создать постоянное табличное пространство по умолчанию, отличное от SYSTEM, которое будет использоваться в качестве стандартного пространства базы данных для постоянных объектов. Отделяя пользовательские данные от системных, вы снижаете вероятность возникновения проблем с табличным пространством SYSTEM, которые в некоторых случаях могут привести к тому, что вся база данных станет нефункциональной. Это постоянное табличное пространство по умолчанию не используется системными пользователями, то есть SYS , SYSTEM и OUTLN , чье постоянное табличное пространство по умолчанию остается SYSTEM . Табличное пространство, обозначенное как постоянное табличное пространство по умолчанию, не может быть удалено. Для достижения этой цели необходимо сначала назначить другое табличное пространство в качестве постоянного табличного пространства по умолчанию. Можно ИЗМЕНИТЬ постоянное табличное пространство по умолчанию на другое табличное пространство, затрагивающее всех пользователей или объекты, созданные после фиксации ALTER DDL.

Вы также можете установить пользовательское табличное пространство по умолчанию во время создания пользователя и изменить его позже с помощью оператора ALTER USER. Изменение пользовательского табличного пространства по умолчанию влияет только на объекты, созданные после изменения параметра.

Когда вы указываете табличное пространство по умолчанию для пользователя, также укажите квоту на это табличное пространство.

В примере 11-1 табличным пространством по умолчанию для пользователя jward является data_ts , а его квота на это табличное пространство составляет 500 КБ .

Назначение квот табличного пространства

Вы можете назначить каждому пользователю квоту табличного пространства для любого табличного пространства (кроме временного табличного пространства). При назначении квоты выполняются следующие действия:

Пользователи с правами на создание определенных типов объектов могут создавать эти объекты в указанном табличном пространстве.

Oracle Database ограничивает объем пространства, которое может быть выделено для хранения пользовательских объектов в указанном табличном пространстве, размером квоты.

По умолчанию у пользователя нет квоты на какое-либо табличное пространство в базе данных. Если у пользователя есть привилегия на создание объекта схемы, необходимо назначить квоту, позволяющую пользователю создавать объекты. Как минимум, назначьте пользователям квоту для табличного пространства по умолчанию и дополнительные квоты для других табличных пространств, в которых они могут создавать объекты.

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

Вы можете назначить квоты пользовательскому табличному пространству при создании пользователя или добавить или изменить квоты позже. Если новая квота меньше старой, то выполняются следующие условия:

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

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

Отзыв возможности пользователя создавать объекты в табличном пространстве

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

НЕОГРАНИЧЕННАЯ системная привилегия TABLESPACE

Чтобы разрешить пользователю использовать неограниченное количество любого табличного пространства в базе данных, предоставьте пользователю системную привилегию UNLIMITED TABLESPACE. Это отменяет все явные квоты табличного пространства для пользователя. Если позже вы отзовете эту привилегию, явные квоты снова вступят в силу. Вы можете предоставить это право только пользователям, но не ролям.

Прежде чем предоставлять системную привилегию UNLIMITED TABLESPACE, вы должны рассмотреть последствия этого.

Вы можете предоставить пользователю неограниченный доступ ко всем табличным пространствам базы данных с помощью одного оператора.

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

Вы не можете выборочно отозвать доступ к табличному пространству у пользователя с привилегией UNLIMITED TABLESPACE. Вы можете предоставить выборочный или ограниченный доступ только после отзыва привилегии.

Назначение временного табличного пространства

Каждому пользователю также должно быть назначено временное табличное пространство. Когда пользователь выполняет оператор SQL, требующий временного сегмента, Oracle сохраняет этот сегмент во временном табличном пространстве пользователя. Эти временные сегменты создаются системой при сортировке или объединении и принадлежат SYS , у которого есть права доступа к ресурсам во всех табличных пространствах.

В предыдущем операторе CREATE USER временным табличным пространством jward является temp_ts , табличное пространство, созданное явно для содержания только временных сегментов. Такое табличное пространство создается с помощью оператора CREATE TEMPORARY TABLESPACE.

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

Если ваше табличное пространство SYSTEM управляется локально, то пользователям должно быть назначено конкретное временное табличное пространство по умолчанию (локально управляемое). Им может быть запрещено по умолчанию использовать табличное пространство SYSTEM, поскольку временные объекты нельзя размещать в постоянных локально управляемых табличных пространствах.

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

Несколько временных табличных пространств: использование групп табличных пространств

Указание профиля

Вы также указываете профиль при создании пользователя. Профиль — это набор ограничений на ресурсы базы данных и пароль доступа к базе данных. Если профиль не указан, пользователю назначается профиль по умолчанию.

Настройка ролей по умолчанию

Вы не можете установить роли по умолчанию для пользователя в операторе CREATE USER. Когда вы впервые создаете пользователя, параметр роли по умолчанию для пользователя — ALL , что приводит к тому, что все роли, впоследствии предоставленные пользователю, будут ролями по умолчанию. Используйте оператор ALTER USER, чтобы изменить роли пользователя по умолчанию.

Изменение пользователей

Пользователи могут изменять свои собственные пароли.Однако, чтобы изменить любую другую опцию домена безопасности пользователя, вы должны иметь системную привилегию ALTER USER. Администраторы безопасности обычно являются единственными пользователями, имеющими эту системную привилегию, поскольку она позволяет модифицировать любой домен безопасности пользователя. Эта привилегия включает в себя возможность устанавливать квоты табличного пространства для пользователя в любом табличном пространстве в базе данных, даже если пользователь, выполняющий изменение, не имеет квоты для указанного табличного пространства.

Вы можете изменить настройки безопасности пользователя с помощью инструкции ALTER USER. Изменение настроек безопасности пользователя влияет на будущие сеансы пользователя, а не на текущие сеансы.

Следующий оператор изменяет параметры безопасности для пользователя, avyrros :

Здесь оператор ALTER USER изменяет параметры безопасности для пользователя avyrros следующим образом:

Аутентификация изменена на использование учетной записи операционной системы пользователя avyrros .

Табличное пространство по умолчанию и временное табличное пространство явно устанавливаются для пользователя avyrros .

avyrros выделяется 100-мегабайтной квотой для табличного пространства data_ts.

Квота на test_ts отменена для пользователя avyrros .

avyrros назначен профиль клерка.

Изменение механизма аутентификации пользователя

Большинство пользователей, не являющихся администраторами баз данных, по-прежнему могут изменять свои собственные пароли с помощью инструкции ALTER USER следующим образом:

Для смены паролей пользователю не требуются специальные привилегии (кроме тех, которые необходимы для подключения к базе данных). Пользователей следует поощрять к частой смене паролей.

Пользователи должны иметь привилегию ALTER USER для переключения между методами аутентификации. Обычно это право есть только у администратора.

"Методы аутентификации пользователей" для получения информации о методах аутентификации, доступных для пользователей базы данных Oracle

Изменение ролей пользователя по умолчанию

Роль по умолчанию — это роль, которая автоматически включается для пользователя, когда пользователь создает сеанс. Вы можете назначить пользователю ноль или более ролей по умолчанию.

Исключение пользователей

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

Если пользовательская схема и связанные объекты должны остаться, но пользователю должен быть запрещен доступ к базе данных, отзовите у пользователя привилегию CREATE SESSION.

Не пытайтесь удалить пользователя SYS или SYSTEM. Это приведет к повреждению вашей базы данных.

Пользователя, который в данный момент подключен к базе данных, нельзя удалить. Чтобы удалить подключенного пользователя, вы должны сначала завершить пользовательские сеансы с помощью оператора SQL ALTER SYSTEM с предложением KILL SESSION.

Вы можете удалить пользователя из базы данных с помощью инструкции DROP USER. Чтобы удалить пользователя и все объекты пользовательской схемы (если они есть), вы должны иметь системную привилегию DROP USER. Поскольку системная привилегия DROP USER является мощной, администратор безопасности обычно является единственным типом пользователей, у которых есть эта привилегия.

Если схема пользователя содержит какие-либо зависимые объекты схемы, используйте параметр CASCADE, чтобы успешно удалить пользователя и все связанные объекты и внешние ключи, которые зависят от таблиц пользователя. Если вы не укажете CASCADE и схема пользователя содержит зависимые объекты, будет возвращено сообщение об ошибке, и пользователь не будет удален. Прежде чем удалять пользователя, схема которого содержит объекты, тщательно изучите, какие объекты содержит схема пользователя, и последствия их удаления. Обратите внимание на любые неизвестные каскадные эффекты. Например, если вы собираетесь удалить пользователя, владеющего таблицей, проверьте, не зависят ли какие-либо представления или процедуры от этой конкретной таблицы.

Следующий оператор удаляет пользователя, jones и все связанные объекты и внешние ключи, которые зависят от таблиц, принадлежащих jones .

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

Просмотр информации о пользователях и профилях базы данных

Большое разнообразие вариантов, доступных для просмотра такой информации, обсуждается в следующих подразделах:

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