A while back in an Office Hours session, I touched on a relatively new privilege in the database called INHERIT PRIVILEGES which is designed to avoid erroneous privilege escalation via AUTHID CURRENT_USER routines.
You can watch the full video below
But in a nutshell, it protects against of the concept of a low privileged account “asking” a higher privileged account to run something in order to get access to those higher privileges. In human terms, this is a me phoning the DBA and saying: “Hi, could you run my procedure for me?” when deep down inside the code of that procedure I’ve embedded something nasty.
The INHERIT PRIVILEGES is a new privilege that can be used to guard against such scenarios, but we had a question on AskTOM on where to find such grants. Interestingly, even though it is a privilege given on a user to a user, if you need to find where the privileges are granted, you need to look in DBA_TAB_PRIVS, and the user that is the subject of the privilege will be found in the TABLE_NAME column. Go figure 🙂
SQL> select grantee, table_name, privilege
2 from dba_tab_privs
3 where privilege = 'INHERIT PRIVILEGES';
GRANTEE TABLE_NAME PRIVILEGE
------------------------------ ------------------------------ ---------------------
XDB SYS INHERIT PRIVILEGES
CTXSYS SYS INHERIT PRIVILEGES
PUBLIC PUBLIC INHERIT PRIVILEGES
PUBLIC XS$NULL INHERIT PRIVILEGES
GSMADMIN_INTERNAL GSMCATUSER INHERIT PRIVILEGES
CTXSYS XDB INHERIT PRIVILEGES
PUBLIC HR INHERIT PRIVILEGES
PUBLIC SCOTT INHERIT PRIVILEGES
PUBLIC ASKTOM INHERIT PRIVILEGES
This is not to be confused with the system privilege INHERIT ANY PRIVILEGES which can be found in the usual place, DBA_SYS_PRIVS
SQL> select * from DBA_SYS_PRIVS
2 where privilege like '%INHERIT%';
GRANTEE PRIVILEGE ADM COM INH
------------------------------ ---------------------------------------- --- --- ---
APEX_180100 INHERIT ANY PRIVILEGES NO NO NO
GSMADMIN_INTERNAL INHERIT ANY PRIVILEGES NO NO NO
APEX_180200 INHERIT ANY PRIVILEGES NO NO NO
DBSNMP INHERIT ANY PRIVILEGES NO YES YES
ORDPLUGINS INHERIT ANY PRIVILEGES NO YES YES
XDB INHERIT ANY PRIVILEGES NO YES YES
MDSYS INHERIT ANY PRIVILEGES NO YES YES
SYS INHERIT ANY PRIVILEGES NO YES YES
WMSYS INHERIT ANY PRIVILEGES NO YES YES
CTXSYS INHERIT ANY PRIVILEGES NO YES YES
ORACLE_OCM INHERIT ANY PRIVILEGES NO YES YES
ORDSYS INHERIT ANY PRIVILEGES NO YES YES
You can read all about INHERIT PRIVILEGES in the docs here
Hello Connor,
I think that there is a small confusion in the above statement.
The user that has received the privilege in NOT in the TABLE_NAME column, but in the GRANTEE
column, as usual.
It just happens that the object on which this privilege is granted is by itself a database USER name,
and this is the user name that appears in the TABLE_NAME column.
So, there is some consistency here, except for the fact that the dictionary view is named
DBA_TAB_PRIVS, rather than being named more generically DBA_OBJECT_PRIVS,
because it stores privileges on all kinds of database objects, not just on tables.
Cheers & Best Regards,
Iudith Mentzel
Agreed, poor wording on my part. I’ll update the entry. Then again, “objects” is perhaps not a great term either, because you won’t find users in the SYS.OBJ$ table.