Privileges and Role Authorization – Part 3

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

Privileges and Role Authorization – Part 3

Managing User Roles:

Creating a Role

You use the “CREATE ROLE” statement to create a role.  You will need the “CREATE ROLE” system privilege to execute this command.  This system privilege is usually limited to security administrators.

Immediately after creating the role, it has no privileges associated with it.  You will continue by granting privileges and other roles to this role.

Roles are not contained in any schema, so the role name is database wide.  Oracle recommends that a role name, should contain at least one single byte character, if the database is using a multibyte character set.  The reason for this is that if the role name contains only multibyte characters, then the encrypted role name and password combination is less secure; as compared to having single byte characters mixed in.

Creating a Role identified by a password:

 A password protected role provides a measure of security.  For example a user can log in and grant a certain role to him/her self.  They will then have access to everything that has been granted in that role.  If the role has a password associated with it, then you have closed this particular security hole.  A role can be created as “NOT IDENTIFIED” or as “IDENTIFIED BY”.  A Role can be protected by a password in the database.  A Role can be authorized by an application, which invokes a specific package.  A Role can be authorised by the Operating system or network.  A role can be authorized Globally by an enterprise directory service.

For example:

SQL> create role fred identified by fred123;   

You can change the way a role is authorized after its creation by using the

SQL> ALTER ROLE …

Syntax.

Secure application roles and password protected roles can only be granted to users, and not to other roles

Of course you could also have opted to alter the way the role is authorized, for example:

SQL>  ALTER ROLE fred IDENTIFIED EXTERNALLY;

In order to be able to alter the authorization method for a role, you must have the “ALTER ANY ROLE” system privilege.  Alternatively if you were granted the role with the ADMIN option you can also change the authorization method.  So be careful about granting roles to users with the ADMIN option.

Specifying the Type of Role Authorization:

Remember that a role must be enabled before you can use it.  There are different ways to authorize a Role.

Authorise a Role by using the Oracle Database:

To do this you just need to assign a password to the role.  Now let’s say that a user has been granted a Role that is protected by a password.  You can’t grant a password protected role to another role.

You can then enable or disable the role for the user by using the “SET ROLE” statement.  For example: SQL> SET ROLE fred IDENTIFIED by <password>; This needs to be done explicitly.

If you are using a multibyte character set in your database, remember that you must use only single byte characters for the password, because multibyte characters are not currently supported in passwords.

Authorizing a Role by Using an Application:

The security design may have included an “application role”, or a “secure application role”.  The secure application role can only be enabled by an authorized PL/SQL package.

SQL> CREATE ROLE fred IDENTIFIED USING <package_name>;

This means that application developers do not need to embed passwords inside their applications.  All the application developer needs to do is to create an application role and specify which PL/SQL package will authorize the role.  The application role can be enabled by any module that is defined within the specified PL/SQL package.

For example:

SQL> CREATE ROLE fred_admin IDENTIFIED USING jim.admin;

Authorizing a Role by Using an External Source:

You can define the external role locally in the database.  You can authorize the role with the operating system or with a network client. 

However you can’t grant the external role to global users, or global roles, or other roles.  You can only grant the external role to a specific user.

For example:

SQL> CREATE ROLE freds_accounts IDENTIFIED EXTERNALLY;

·         Authorizing a Role by using the Operating system:  This is an Operating system dependent operation.  You need to configure information for each user at the operating system level.  You can only use operating system Role authentication when the operating system is able to dynamically link operating system privileges with applications.  For example when a user starts an application, the operating system grants an operating system privilege to the user.  The system privilege from the operating system, matches or corresponds to the appropriate role that is associated with the application.  At this point in time the application enables the application role.  When the application is ended or terminated by the user, then the operating system privilege is again revoked from the user account.

·         Authorizing a Role by Using a Network Client: By default the initialization parameter REMOTE_OS_ROLES is set to FALSE.  This means that by default if a user connects to the database over Oracle Net, then the operating system cannot authenticate their roles.  This default behaviour protects the database from users who may be impersonating a registered user over the network connection.  If you are not concerned with this security risk, and want to use operating system role authentication for network clients then: set the initialization parameter. REMOTE_OS_ROLES=TRUE

Global Role Authorization by an Enterprise Directory Service:

You can define a role as a “Global” role.  To do this you define the role in the database and grant other roles and privileges to it.  You cannot grant such a global role to any other role or user in the database.

The Global role is granted to a user when they connect to the database through an Enterprise Directory Service.  The global roles associated with the user are assigned at this point in the connection process.

SQL> CREATE ROLE fred_super IDENTIFIED GLOBALLY;

·         Global roles are a component of enterprise user security

·         Global roles apply to one database only

·         Enterprise role is defined in the enterprise directory.  An enterprise role consists of a directory structure that contains global roles from multiple databases.  An enterprise role can be granted to enterprise users

Granting and Revoking Roles:

A role consists of system and/or object privileges that have been granted to that role.  A role can be granted to any database user or to another role, provided that there are no specific restrictions in this regard.

A role can’t be granted to itself.  A role can’t be granted in a circular configuration, for example:  Role A can’t be granted to Role B, if Role B has already been granted to Role A.

The Oracle Database Server permits applications and users to enable and to disable roles.  Each role that is granted, will be either enabled or disabled.  The security domain of a user consists of all the privileges of all the roles that are currently enabled for a user.  The security domain of a user excludes all the privileges of any roles that are currently disabled for that user.

Indirectly granted roles are roles that have been granted to a role, that has been granted to a user.  When you enable or disable a role for a user, you in effect enable or disable all the indirectly granted roles for that user.

There are two ways to grant and revoke roles from users or other roles.  Firstly you can use Oracle Enterprise Manager Database Control, Secondly you can use the GRANT and REVOKE statements in SQL*Plus.  To grant and revoke privileges from a role, you would use the same method.

Users who can Grant and/or Revoke Roles:

You need the “GRANT ANY ROLE” system privilege, to be able to grant or revoke any role to other users or roles in the database, with the exception of Global Roles; because global roles are managed in Oracle Internet Directory.  By default the SYS and SYSTEM users have this privilege.  Be careful about granting this privilege to other users, because it is a very powerful privilege.  Any user who has been granted a role with the “ADMIN” option, can grant and revoke that role to other users and roles in the database.  The ADMIN option effectively creates selective administrative powers for specific roles, which is more secure than granting the “GRANT ANY ROLE” system privilege.

Dropping Roles:

Dropping a role automatically removes it from all user default role lists.  All indirectly granted roles are also removed from user default role lists.  The security domains of all users and roles that were granted a dropped role whether directly or indirectly, are immediately changed to reflect the absence of the dropped role/s.

Of course objects that are referenced in a role, may appear to have disappeared when the role is dropped or revoked.  In fact the objects are independent of the grants on the object, so the objects continue to exist.  Access or privileges on the specific objects are potentially lost, when the role is dropped.

In order to drop a role you will need the “DROP ANY ROLE” system privilege, or have been granted the role with the ADMIN option. For example:

SQL> DROP ROLE fred;

Restricting SQL*Plus Users from Using Database Roles:

SQL*Plus users and users of other ad-hoc tools, can present serious security problems which are multiplied when these users are able to use database roles.

Potential Security Problems of Using Ad Hoc tools

Database applications can explicitly control the actions of a user, and enable and disable the user roles for that user while the application runs.  On the other hand SQL*Plus and other ad hoc tools permit a user to execute whatever SQL statement they have permission to execute.  For example roles can be enabled and disabled from an ad hoc tool.

A user operating an ad hoc tool has the potential to issue destructive SQL statements against the database tables and other objects in the database.

For example:

Let’s say that the accounts receivable application has an accounts_receivable role, which is granted to users of the application.  This role includes the privileges needed to execute selects, inserts, updates and deletes against the financial tables in the application.  When accessing the data through the application, the application controls how things are done, and the specific operations that are allowed according to a defined set of rules.

Now let’s suppose that a user who has been granted the “accounts_receivable” role logs into the database via an ad hoc tool like SQL*Plus.  Now this user has all the privileges that are granted through the accounts_receivable role.  This user can select data, update data, insert data, and even delete data.  However because the access is made through an ad hoc tool, none of the defined set of rules is applied to the actions that the user can carry out.  The user can modify data, insert data, and delete data, and then query the data to see the results of the action.

Limiting Roles Through the PRODUCT_USER_PROFILE table

You can use the object SYSTEM.PRODUCT_USER_PROFILE to limit commands in the SQL*Plus environment for individual users. You can also restrict access to the GRANT, REVOKE, and SET ROLE commands to control the user’s ability to change their database privileges in a SQL*Plus environment.

You could for example create an entry in the system.product_user_profile object, to prevent user fred from using the “HOST” command while in SQL*Plus.

As the system user:

SQL> INSERT INTO system.product_user_profile

(product, userid, attribute, scope, numeric_value, char_value, date_value, long_value)

VALUES

('SQL*Plus', 'FRED', 'HOST', NULL, NULL, 'DISABLED', NULL, NULL);

SQL> commit;

To show that user fred has effectively had the HOST command disabled in the SQL*Plus sessions:

SQL> connect fred/<password>

Connected.

SQL> host

SP2-0544: Command "host" disabled in Product User Profile

To start setting up this functionality, you must run the following command as SYSTEM, if it has not been previously run.

SQL> {$ORACLE_HOME}/sqlplus/admin/pupbld.sql

This will create the following data dictionary objects for you.

Product_profile, Product_user_profile

SQL> l

  1  select owner, SYNONYM_NAME,TABLE_OWNER,TABLE_NAME

  2* from dba_synonyms where SYNONYM_NAME in ('PRODUCT_PROFILE','PRODUCT_USER_PROFILE')

SQL> /

OWNER      SYNONYM_NAME           TABLE_OWNE TABLE_NAME

---------- ---------------------- ---------- ------------------------------

SYSTEM     PRODUCT_USER_PROFILE   SYSTEM     SQLPLUS_PRODUCT_PROFILE

PUBLIC     PRODUCT_PROFILE        SYSTEM     PRODUCT_PRIVS

PUBLIC     PRODUCT_USER_PROFILE   SYSTEM     PRODUCT_PRIVS

There are a number of SQL*Plus commands that can be disabled using this functionality:

COPY, DECLARE, EDIT, EXECUTE, EXIT, GET, HOST, PASSWORD, QUIT, RUN, SAVE, SET, SPOOL, START

Then there are a number of straight forward SQL commands that can be disabled using this functionality:

ALTER, ANALYZE, AUDIT, CONNECT, CREATE, DELETE, DROP, GRANT, INSERT, LOCK, NOAUDIT, RENAME, REVOKE, SELECT, SET CONSTRAINTS, SET ROLE, SET TRANSACTION, TRUNCATE, UPDATE

To disable a SQL or SQL*Plus command for the user ‘FRED’,  insert a row containing the user’s username in the USERID column, the command name in the ATTRIBUTE column, and ‘DISABLED’ in the CHAR_VALUE column.

Insert into system.product_user_profile

(product, userid, attribute, scope, numeric_value, char_value, date_value, long_value)

Values

(‘SQL*Plus’,’FRED’,’DELETE’,NULL,NULL,’DISABLED’,’NULL,NULL);

Commit;

When you give the USERID field the value of ‘PUBLIC’, or ‘%’, then the command will be effective for all users.  For example if you want to prevent all users from spooling from the SQL*Plus prompt:

Insert into system.product_user_profile

(product, userid, attribute, scope, numeric_value, char_value, date_value, long_value)

Values

(’SQL*Plus’,’%’,’SPOOL’,NULL,NULL,’DISABLED’,NULL,NULL);

SQL> spool fred.txt

SP2-0606: Cannot create SPOOL file "fred.txt"

To re-enable commands you simply delete the row containing the restriction.

Using Stored Procedures to Encapsulate Business Logic

Stored procedures encapsulate the privileges that are needed, together with the business logic.  In this way the privileges are only exercised in the context of a properly controlled business transaction.

The use of the procedure can be limited to normal business hours, in order to prevent people from making changes on the system outside of business hours.  Update privileges on a table can be granted on the procedure instead of to the user.  In this way the table can only be updated, if accessed in the designed way through the procedure.  This deny the user the possibility of accessing the table and doing updates through an ad hoc tool such as SQL*Plus.

Securing Role Privileges by Using Secure Application Roles:

A secure application role can only be enabled by an authorized PL/SQL package or procedure.  The PL/SQL package reflects the privileges and security policies needed to control access to the application.

This arrangement limits or restricts the enabling of this type of role to the invoking application.  The application can verify within itself before executing the package, whether the user has connected through a proxy, and whatever other validation is needed.

A secure application role strengthens the system security, because you do not need to embed passwords in the application or in a table for that matter.  Using this method the application is limited to actions that are defined in the security policies.  These definitions are stored in the application in one place.  You can modify security policies in one place without having to recompile the application.

To enable the secure application role, you must execute its underlying package, by invoking it directly from the application once the user has logged in.  It needs to be executed before the user exercises the privileges that have been granted to the secure application role.  You can’t use a logon trigger to enable a secure application role.  A secure application role cannot be a default role.

When you enable the secure application role from the application, Oracle Database Server verifies that the authorized PL/SQL package is on the calling stack.  In other words, Oracle Database verifies that the authorized PL/SQL package is issuing the command to enable the role, and not some other process.

You can verify that there is a database connection associated with the user that is trying to authorize the role within the package, this can prevent unauthorized processes from within the Oracle Database Server from invoking the role.

Because the role is implemented by a package, the package can execute additional steps like looking for a specific IP range, or validating that the user connected from a specific middle tier.  Users are ultimately forced to work within the framework of the application.  The same user would not have access to the privileges if that user were to be outside of the application.

Franz Devantier,

Need a database health check?

devantierf@gmail.com

Income stabilizer (win-win opportunity)

Join the carefully selected and tested cash-flow generating program below to potentially create a long-term residual or annuity type income enhancer for yourself.

Traffic Wave - Free Report:  The report will give you all the information you need to start making a nice long-term residual income stream for yourself.

Privileges and Role Authorization – Part 2

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

Privileges and Role Authorization – Part 2

Managing User Roles:

User Roles

It is easier to maintain and control lists of privileges, when they are grouped together into a role.  A role can then be granted to users or other roles, and carries with it the list of privileges that is defined in it.  The uniqueness of a role is database wide, and not schema wide, as with other database objects such as tables.  Roles are not contained in a schema.  If a user creates a role, and then that use is dropped, the role continues to exist.

Roles are a quick easy and efficient way of granting groups of permissions to users.  You can use the database pre-defined roles, such as the CONNECT role, which now only has the CREATE SESSION privilege in it.  You would probably want to create your own roles, to suit your specific requirements.

·         A role can be granted system or object privileges

·         A role can be granted to any database user

·         For a given user, a granted role can be either enabled or disabled.  Database users and applications can selectively enable and disable roles to provide selective availability of privileges

·         A role can be granted to other roles.  However a role can’t be granted circularly, for example you can’t grant role A to role B, if role B is already granted to role A

·         A role can be granted indirectly to a user, for example if you grant role A to a user, and Role B has been granted to role A, then you have indirectly granted role B to the user.  Enabling and disabling role A, enables and disables Role B as well.  However if the role is password authenticated or a secure application role, then you can’t grant the role indirectly to a user

·         You have the option of making a directly granted role the default role, using the “DEFAULT ROLE” clause of the “ALTER USER” statement.  Remember you can only make roles default roles that have been directly granted to the user.  To find the directly granted roles for a user.

SQL> select grantee, granted_role from dba_role_privs where grantee = 'FRED';

To determine which roles have been granted to other roles;

SQL> select role, granted_role from role_role_privs where role = 'DBA' order by 2;

ROLE                           GRANTED_ROLE

------------------------------ ------------------------------

DBA                            DATAPUMP_EXP_FULL_DATABASE

DBA                            DATAPUMP_IMP_FULL_DATABASE

DBA                            DELETE_CATALOG_ROLE

DBA                            EXECUTE_CATALOG_ROLE

DBA                            EXP_FULL_DATABASE

DBA                            GATHER_SYSTEM_STATISTICS

DBA                            IMP_FULL_DATABASE

DBA                            JAVA_ADMIN

DBA                            JAVA_DEPLOY

DBA                            OLAP_DBA

DBA                            OLAP_XS_ADMIN

DBA                            SCHEDULER_ADMIN

DBA                            SELECT_CATALOG_ROLE

DBA                            WM_ADMIN_ROLE

DBA                            XDBADMIN

DBA                            XDB_SET_INVOKER

16 rows selected.

·         Password authenticated and secure application roles, can only be granted directly to a user.  To set these types of roles: SQL> set role fred_role identified by fred123;

How the properties of roles facilitate easier privilege management in a database.

Property	Explanation
Reduced privilege administration	Rather than granting the same set of privileges explicitly to several users, you can grant the privileges for a group of related users to a role, and then only the role must be granted to each member of the group.
Dynamic privilege management	If the privileges of a group must change, then only the privileges of the role need to be modified. The security domains of all users granted the group's role automatically reflect the changes made to the role.
Selective availability of privileges	You can selectively enable or disable the roles granted to a user. This allows specific control of a user's privileges in any given situation.
Application awareness	The data dictionary records which roles exist, so you can design applications to query the dictionary and automatically enable (or disable) selective roles when a user attempts to execute the application by way of a given user name.
Application-specific security	You can protect role use with a password. Applications can be created specifically to enable a role when supplied the correct password. Users cannot enable the role if they do not know the password.

You can grant a secure application role, all the privileges needed to run an application.  You can then grant this secure application role to other roles or users.  A more complex application can have several different roles, each of these application roles allowing specific data access, for example HR or Finance.  Password protected roles, prevent the roles from being used for security breaches.  Typically an application should be designed, so that when it starts, it determines the functionality required by the current user, and enables the appropriate role.  The Application user would not need to know the password for an application role.  A fairly complex application with diverse functionality like finance, HR, etc; should not have one application role that grants all the privileges for the entire application.  This would be a security risk.

How Roles are Commonly Used:

·         They could be used to manage the privileges of a database application

·         They could be used to manage the privileges for a user group

·         You can grant an application role all the privileges that are needed to run a database application, or create several application roles to cater for the application.

·         You can create a role for a group of database users, with common privilege requirements.

For example collections of application privileges are assigned to one or more application roles.  These application roles are then assigned to user roles in different combinations, so that you end up with a finance role, a manager role, a clerk role etc.  These user roles are then assigned to various end-users.

·         The security domain of a role includes the privileges granted to the role, plus those privileges that are granted to the roles that are granted to that role.

·         The Security domain of a user includes all the schema objects in the corresponding schema, and the privileges granted to that user. Also all the privileges of all the roles that are granted to that user and are currently enabled.  Also the privileges and roles that are granted to the PUBLIC role.

·         Roles can be simultaneously enabled for some users and disabled for other users.

·         Named PL/SQL block executed with Definer’s Rights; All the roles are disabled.

·         Named PL/SQL blocks executed with Invoker’s rights or Anonymous blocks, are executed based on the privileges granted through enabled roles.

Roles affect the usage of DDL statements.  For example to create a table the user may require the “CREATE TABLE” privilege.  The Oracle database restricts the use of certain specific privileges in certain DDL statements.

·         All system and object privileges that permit a user to perform DDL statements are usable when received through a role.  With the exception of the “REFERENCES” object privilege with regards to defining a foreign key for a table.

All system and object privileges that allow a user to perform a DML operation that is required to execute a DDL statement are not usable when received through a role.  The security Domain does not contain roles when a “CREATE VIEW” statement is used.  For example a user who is granted the “SELECT TABLE” privilege on another users table through a role, cannot use this privilege to create a view on that same table that belongs to another user.

The reason for this is because views are definers rights objects.  When creating a view you cannot use any system or object privileges that have been granted through a role.  However if the privilege had been granted directly to you, then you could have used the privilege.  If the privilege is revoked from your user after creating the view, then the view becomes invalid.

For example:

·         The user is granted a role that has the “CREATE VIEW” system privilege

·         The user is granted a role that has the “SELECT TABLE” privilege for the fruit table

·         The user is granted the “SELECT TABLE” privilege for the veggie table

As a result:

·         The user can select data from both the fruit and veggie tables, which are in other users schemas

·         The user cannot create a view on the fruit table, because the “SELECT TABLE” privilege was granted through a view

·         The user can create a view on the veggie table, because the “SELECT TABLE” privilege was granted directly to the user

In UNIX/LINUX environments, you can administer database security using the operating system. The operating system can be used to grant and revoke database roles and to manage their password authentication. This capability is not available on all operating systems.

When you use roles in a distributed environment, there is one other consideration.  You cannot enable a role through a remote procedure.  SO you need to make sure that all the roles at the remote site, are enabled or set as default roles for a distributed or remote session.

Predefined Roles

Oracle ships with a set of pre-defined roles.  These roles are defined when you create the database.  If you install additional options / products, the additional predefined roles are created.  You can grant and revoke privileges and roles from these pre-defined roles, in the same way that you can with any other user defined roles.  It would be a good idea to document the changes you make to the predefined roles.

Predefined Role	Notes
ADM_PARALLEL_EXECUTE_TASK	Provides privileges to update table data in parallel by using the DBMS_PARALLEL_EXECUTE PL/SQL package.
AQ_ADMINISTRATOR_ROLE	Provides privileges to administer Advanced Queuing. Includes ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, and MANAGE ANY QUEUE, SELECT privileges on Advanced Queuing tables and EXECUTE privileges on Advanced Queuing packages.
AQ_USER_ROLE	Obsolete, but kept mainly for release 8.0 compatibility. Provides EXECUTE privileges on the DBMS_AQ and DBMS_AQIN packages.
AUTHENTICATEDUSER	Used by the XDB protocols to define any user who has logged in to the system.
CAPI_USER_ROLE	Provides access to packages used for implementing Information Lifecycle Management (ILM) and hierarchical storage and other applications.
CONNECT	Provides the CREATE SESSION system privilege. This role is provided for compatibility with previous releases of Oracle Database. You can determine the privileges encompassed by this role by querying the DBA_SYS_PRIVS data dictionary view. Note: Oracle recommends that you design your own roles for database security rather than relying on this role. This role may not be created automatically by future releases of Oracle Database.
CSW_USR_ROLE	Provides user privileges to manage the Catalog Services for the Web (CSW) component of Oracle Spatial.
CTXAPP	Provides privileges to create Oracle Text indexes and index preferences, and to use PL/SQL packages. This role should be granted to Oracle Text users.
CWM_USER	Provides privileges to manage Common Warehouse Metadata (CWM), which is a repository standard used by Oracle data warehousing and decision support.
DATAPUMP_EXP_FULL_DATABASE	Provides privileges to export data from an Oracle database using Oracle Data Pump. Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.
DATAPUMP_IMP_FULL_DATABASE	Provides privileges to import data into an Oracle database using Oracle Data Pump. Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.
DBA	Provides all system privileges that were created with the ADMIN option. This role is provided for compatibility with previous releases of Oracle Database. You can determine the privileges encompassed by this role by querying the DBA_SYS_PRIVS data dictionary view. Note: Oracle recommends that you design your own roles for database security rather than relying on this role. This role may not be created automatically by future releases of Oracle Database
DELETE_CATALOG_ROLE	Provides the DELETE privilege on the system audit table (AUD$).
EJBCLIENT	Provides privileges to connect to EJBs from a Java stored procedure.
EXECUTE_CATALOG_ROLE	Provides EXECUTE privileges on objects in the data dictionary.
EXP_FULL_DATABASE	Provides the privileges required to perform full and incremental database exports using the Export utility (later replaced with Oracle Data Pump). It includes these privileges: SELECT ANY TABLE, BACKUP ANY TABLE, EXECUTE ANY PROCEDURE, EXECUTE ANY TYPE, ADMINISTER RESOURCE MANAGER, and INSERT, DELETE, and UPDATE on the tables SYS.INCVID, SYS.INCFIL, and SYS.INCEXP. Also the following roles: EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE. This role is provided for convenience in using the export and import utilities. Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.
GATHER_SYSTEM_STATISTICS	Provides privileges to update system statistics, which are collected using the DBMS_STATS.GATHER_SYSTEM_STATISTICS procedure
GLOBAL_AQ_USER_ROLE	Provides privileges to establish a connection to an LDAP server, for use with Oracle Streams AQ.
HS_ADMIN_EXECUTE_ROLE	Provides the EXECUTE privilege for users who want to use the Heterogeneous Services (HS) PL/SQL packages.
HS_ADMIN_ROLE	Provides privileges to both use the Heterogeneous Services (HS) PL/SQL packages and query the HS-related data dictionary views.
HS_ADMIN_SELECT_ROLE	Provides privileges to query the Heterogeneous Services data dictionary views.
IMP_FULL_DATABASE	Provides the privileges required to perform full database imports using the Import utility (later replaced with Oracle Data Pump). Includes an extensive list of system privileges (use view DBA_SYS_PRIVS to view privileges) and the following roles: EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE. This role is provided for convenience in using the export and import utilities. Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.
JAVADEBUGPRIV	Provides privileges to run the Oracle Database Java applications debugger.
JAVAIDPRIV	Deprecated for this release.
JAVASYSPRIV	Provides major permissions to use Java2, including updating Oracle JVM-protected packages.
JAVAUSERPRIV	Provides limited permissions to use Java2.
JAVA_ADMIN	Provides administrative permissions to update policy tables for Oracle Database Java applications.
JAVA_DEPLOY	Provides privileges to deploy ncomp DLLs into the javavm/admin directory using the ncomp and deployns utilities. Without this role, the javavm/deploy and javavm/admin directories can be accessible.
JMXSERVER	Provides privileges to start and maintain a JMX agent in a database session.
LBAC_DBA	Provides permissions to use the SA_SYSDBA PL/SQL package.
LOGSTDBY_ADMINISTRATOR	Provides administrative privileges to manage the SQL Apply (logical standby database) environment.
MGMT_USER	Grants the SELECT privilege on the different views used for the SYSMAN schema.
OEM_ADVISOR	Provides privileges to create, drop, select (read), load (write), and delete a SQL tuning set through the DBMS_SQLTUNE PL/SQL package, and to access to the Advisor framework using the ADVISOR PL/SQL package.
OEM_MONITOR	Provides privileges needed by the Management Agent component of Oracle Enterprise Manager to monitor and manage the database.
OLAP_DBA	Provides administrative privileges to create dimensional objects in different schemas for Oracle OLAP.
OLAP_USER	Provides application developers privileges to create dimensional objects in their own schemas for Oracle OLAP.
OLAP_XS_ADMIN	Provides privileges to administer security for Oracle OLAP.
ORDADMIN	Provides privileges to administer Oracle Multimedia DICOM.
OWB$CLIENT	Provides privileges to perform standard client-related tasks for Oracle Warehouse Builder, such as creating projects, modules, tables, views, maps, and so on. Warehouse Builder automatically grants this role to all workspace owners and users. (That is, you do not need to explicitly grant it to anyone who must use Warehouse Builder.) For security reasons, the OWB$CLIENT role is not a default role for Warehouse Builder users: Oracle Warehouse Builder enables this role only when it is needed.
OWB_DESIGNCENTER_VIEW	Provides privileges from the database level for any registered Oracle Warehouse Builder user to query the Warehouse Builder public views, such as ALL_IV_PROJECTS. A Warehouse Builder administrator can use the ACCESS_PUBLICVIEW_BROWSER system privilege from the Warehouse Builder security level to control a Warehouse Builder user's access to those public views.
OWB_USER	Provides privileges to create and own an Oracle Warehouse Builder workspace. When a workspace owner registers other database users to this workspace, Oracle Database grants this role to these users. Users with this role also have access to Warehouse Builder Control Center public views and other Control Center utilities. Oracle Warehouse Builder grants this role to all Warehouse Builder users.
RECOVERY_CATALOG_OWNER	Provides privileges for owner of the recovery catalog. Includes: CREATE SESSION, ALTER SESSION, CREATE SYNONYM, CREATE VIEW, CREATE DATABASE LINK, CREATE TABLE, CREATE CLUSTER, CREATE SEQUENCE, CREATE TRIGGER, and CREATE PROCEDURE
RESOURCE	Provides the following system privileges: CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE. This role is provided for compatibility with previous releases of Oracle Database. You can determine the privileges encompassed by this role by querying the DBA_SYS_PRIVS data dictionary view. Note: Oracle recommends that you design your own roles for database security rather than relying on this role. This role may not be created automatically by future releases of Oracle Database.
SCHEDULER_ADMIN	Allows the grantee to execute the procedures of the DBMS_SCHEDULER package. It includes all of the job scheduler system privileges and is included in the DBA role.
SELECT_CATALOG_ROLE	Provides SELECT privilege on objects in the data dictionary.
SNMPAGENT	Used by the Enterprise Manager Management Agent.
SPATIAL_CSW_ADMIN	Provides administrative privileges to manage the Catalog Services for the Web (CSW) component of Oracle Spatial.
SPATIAL_WFS_ADMIN	Provides administrative privileges to manage the Web Feature Service (WFS) component of Oracle Spatial.
WFS_USR_ROLE	Provides user privileges for the Web Feature Service (WFS) component of Oracle Spatial.
WM_ADMIN_ROLE	Provides administrative privileges for Oracle Workspace Manage. This enables users to run any DBMS_WM procedures on all version enabled tables, workspaces, and savepoints regardless of their owner. It also enables the user to modify the system parameters specific to Workspace Manager.
XDBADMIN	Allows the grantee to register an XML schema globally, as opposed to registering it for use or access only by its owner. It also lets the grantee bypass access control list (ACL) checks when accessing Oracle XML DB Repository.
XDB_SET_INVOKER	Allows the grantee to define invoker’s rights handlers and to create or update the resource configuration for XML repository triggers. By default, Oracle Database grants this role to the DBA role but not to the XDBADMIN role.
XDB_WEBSERVICES	Allows the grantee to access Oracle Database Web services over HTTPS. However, it does not provide the user access to objects in the database that are public. To allow public access, you need to grant the user the XDB_WEBSERVICES_WITH_PUBLIC role. For a user to use these Web services, SYS must enable the Web service servlets.
XDB_WEBSERVICES_OVER_HTTP	Allows the grantee to access Oracle Database Web services over HTTP. However, it does not provide the user access to objects in the database that are public. To allow public access, you need to grant the user the XDB_WEBSERVICES_WITH_PUBLIC role.
XDB_WEBSERVICES_WITH_PUBLIC	Allows the grantee access to public objects through Oracle Database Web services.

Franz Devantier,

Need a database health check?

devantierf@gmail.com

Income stabilizer (win-win opportunity)

Join the carefully selected and tested cash-flow generating program below to potentially create a long-term residual or annuity type income enhancer for yourself.

Traffic Wave - Free Report:  The report will give you all the information you need to start making a nice long-term residual income stream for yourself.