The strange place for INHERIT PRIVILEGES

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

2 Comments on “The strange place for INHERIT PRIVILEGES

  1. 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.

Got some thoughts? Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: