Database Reference
In-Depth Information
SQL> grant create session to umtest;
Grant succeeded.
SQL> grant execute on um.um_status to umtest;
Grant succeeded.
SQL> set serveroutput on;
SQL> exec um.um_status.role_sys_priv('UMTEST');
UMTEST has:
SYS PRIV--CREATE SESSION--ADMIN-NO
PL/SQL procedure successfully completed.
SQL> exec um.um_status.role_sys_priv('DBA');
DBA has:
ROLE--DATAPUMP_EXP_FULL_DATABASE
ROLE--EXP_FULL_DATABASE
ROLE--EXECUTE_CATALOG_ROLE
ROLE--HS_ADMIN_EXECUTE_ROLE
ROLE--SELECT_CATALOG_ROLE
ROLE--HS_ADMIN_SELECT_ROLE
SYS PRIV--ADMINISTER RESOURCE MANAGER--ADMIN-NO
SYS PRIV--ADMINISTER SQL MANAGEMENT OBJECT--ADMIN-NO
SYS PRIV--BACKUP ANY TABLE--ADMIN-NO
SYS PRIV--CREATE SESSION--ADMIN-NO
SYS PRIV--CREATE TABLE--ADMIN-NO
SYS PRIV--EXECUTE ANY PROCEDURE--ADMIN-NO
SYS PRIV--EXECUTE ANY TYPE--ADMIN-NO
SYS PRIV--READ ANY FILE GROUP--ADMIN-NO
SYS PRIV--RESUMABLE--ADMIN-NO
SYS PRIV--SELECT ANY SEQUENCE--ADMIN-NO
SYS PRIV--SELECT ANY TABLE--ADMIN-NO
SYS PRIV--CREATE SESSION--ADMIN-NO
SYS PRIV--CREATE TABLE--ADMIN-NO
ROLE--DATAPUMP_IMP_FULL_DATABASE
ROLE--EXP_FULL_DATABASE
.... 8< snipped output
The script handles larger output in a clean and readable way and can take a user or a role, listing the full nested
privileges and roles—but not their passwords.
There are actually at least three valid reasons why it can be useful to confirm a given user's password is correct.
1.
User management for fault finding
2.
To authenticate users from application to DB (not really recommended but might be a
pragmatic solution)
3.
To make sure users have not used default passwords
Search WWH ::




Custom Search