Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








Oracle Grant Security best practices

Oracle Tips by Burleson Consulting
July 28, 2015

For a complete discussion of Oracle grant security, see my book "Oracle Privacy Security Auditing".

Oracle offers many ways to control data access rules, including:

  • Grant security (e.g., system, object, and role privileges)
  • Grant execute security (e.g., definer and invoker rights)
  • Virtual private databases (VPD)
  • N-tier authentication (e.g., RADIUS and authentication servers)

Let's start with the basics by looking at grant security to examine its benefits and pitfalls. The original relational model provides a method for granting privileges to users to allow for access control. This grant model was originally described by E. F. Codd and Chris Date in the original relational model and the model is standard across most commercial relational databases.

Oracle grant security takes several forms: object grants, system privilege grants, and role-based grants. The idea is that every user in the database is granted access to specific data objects to control data access.

Oracle Object privileges best practices

Object privileges assign the right to perform a particular operation on a specific object. Here are some examples of object privilege assignment:

grant select, insert on customer to fred, mary, joe;
grant insert on order_table to update_role;
grant all on customer to fred;
grant select on customer_view to mary;

As you can see, the direct assignment of object privileges requires specific grants for every object to every user in the Oracle database. If you have a schema with 100 tables and 1,000 users, it would require 100,000 individual grant statements to assign security.

Oracle System privileges

System privileges cover many areas of access in a broad brush, with grants such as select any table. Examples of system privilege grants include:

grant create any cluster to customer_role;
grant select any table to fred;
grant create any table to public;
grant create tablespace to dba_role;

Obviously, system privileges should be used only in cases where security isn't important, because a single grant statement could remove all security from the table.

Oracle Role-based security

Role security allows you to gather related grants into a collection. Since the role is a predefined collection of privileges that are grouped together, privileges are easier to assign to users, as in this example:

create role all_customer;

grant select, update on customer to all_customer;
grant select on item_table to all_customer;

grant all_customer to fred, mary, joe;

The benefits of role-based security are obvious, because role-based security allows you to define sets of access rules and then assign them to the appropriate classes of users.

However, unlike VPD security, it isn't possible to implement sophisticated rules for data access. With grants, users either have access to the table, or they do not.

Design for Oracle grant security

If you choose to implement grant security for your Oracle database, you must do some careful up-front planning to ensure that each role is carefully designed to cover access for a specific class of users without overlapping other roles. The steps for implementing grant security are:

  1. Define roles for all known classes of users.
  2. Define access rules for each role.
  3. Define all row-level and column-level restrictions.
  4. Create views for all data access.
  5. Assign the views to the roles.
  6. Assign the roles to the users.

To alleviate the issue of overlapping roles, many Oracle designers create a hierarchy of roles, using roles within roles to exactly match the data access requirements to user groups.

User group access

Note the careful overlap of access privileges between the programmer and analyst roles. It's not uncommon for roles to legitimately overlap when it comes to access, and the Oracle designer must pay careful attention to the access outline.

In the real world, the design of the roles can get quite complex. To illustrate, let's look at a simple example.

Design for row-level and column-level access

In the real world, it isn't enough simply to grant access to whole tables; often you may need to restrict access to specific rows within a table. Without VPDs, the only way to do this with grants is to create separate views for each row-level restriction and then assign the views to the roles and the roles to the users. For example, assume that you must design roles based on the following business rules:

  • Only managers may view the salary column of the employee table (column restriction).
  • Other employees may view only employee names and phone number for publisher P001 (row restriction).

To implement this design within Oracle using role-based security, perform the following steps:

  • Create the base roles for managers and employees.
  • Create the appropriate views.
  • Grant the views to the roles.
  • Grant the roles to the users.

In Oracle, the views in Listing A implement this design scheme.

SQL> create role emp_role;

 Role created.

 SQL> create role mgr_role;

 Role created.

 SQL> create view
2 emp_view
3 as
4 select
5 emp_first_name, emp_last_name
6 from
7 emp
8 where
9 pub_key = 'P001';

 View created.

 SQL> create view
2 mgr_view
  3 as
4 select
5 emp_first_name, emp_last_name, emp_salary
6 from
7 emp;

 View created.

 SQL> -- Grant the privileges to the role
 SQL> grant create session, connect, resource to emp_role, mgr_role;

 Grant succeeded.

 SQL> grant select on emp_view to emp_role;

 Grant succeeded.

 SQL> grant select on mgr_view to mgr_role;

 Grant succeeded.

 SQL> create user fred_emp identified by fred;

 User created.

 SQL> grant emp_role to fred_emp;

 Grant succeeded.

 SQL> create user mary_mgr identified by mary;

 User created.

 SQL> grant mgr_role to mary_mgr;

 Grant succeeded.

Now that you've assigned the appropriate grant statements, test your views and see if they work (Listing B):

SQL> connect fred_emp/fred;
SQL> select * from pubs.emp_view;

EMP_FIRST_NAME EMP_LAST_NAME                                             
-------------------- ------------------------------                            
sam king                                                      
mary korn                                                      

SQL> connect mary_mgr/mary;

SQL> select * from pubs.mgr_view;

EMP_FIRST_NAME       EMP_LAST_NAME          EMP_SALARY                 
-------------------- ---------------------- ----------             
sam                  king                   95000                 
bill                 jackson                35000                 
mary                 korn                   28000                 
fred                 linus                  45000                 
janet                tokheim                63000                
john                 lavender               14000              

Loopholes in grant security

There are several issues with grant security that can create loopholes in your design. These include:

  • Assigning grants to PUBLIC.
  • Assigning roles using the WITH ADMIN option.
  • Overlapping unplanned access roles.
  • Assigning system privileges (select any table) to roles.
  • Creating public synonyms.

For example, within Oracle you can explicitly grant to PUBLIC all tables that you wish to have general read-only access. This system privilege supercedes the role-based security and creates a giant loophole, as in this example:

Create public synonym customer for pubs.customer;
Grant select on customer to public;

Another important loophole is public synonyms for tables. Remember, the default in Oracle is that nobody except the object owner is allowed to perform any operation on the table. Also, the full table name must be specified in the SQL or Oracle will imply that the table does not exist:

connect pubs/pubs

create table
select object_name, object_type from dba_objects;

 Table created.

select count(*) from test_table;


 1 row selected.

Now, when you connect as the user, SCOTT, he is unable to see the table rows, as in the example:

connect scott/tiger

 select count(*) from test_table
 ERROR at line 1:
 ORA-00942: table or view does not exist

In this case, you know that the table exists, but Oracle considers only the fully-qualified table name:

Connect pubs/pubs

 create public synonym test1_table for pubs.test1_table;

 Synonym created.

 Connect scott/tiger

 select count(*) from test_table;


 1 row selected.


Complexity of Oracle Security

Designing Oracle databases for grant security can become phenomenally complex. The issues raised in this article have led to the creation of new methods of Oracle security, most notably the grant execute model and the VPD. In my book "Oracle Privacy Security Auditing", I'll examine database design for these new methods.

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2016

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.