Oracle7 Server Concepts Manual Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index

Go to previous file in sequence Go to next file in sequence

Privileges and Roles

My right and my privilege to stand here before you has been won -- won in my lifetime -- by the blood and the sweat of the innocent.

Jesse Jackson: Speech at the Democratic National Convention, 1988

This chapter explains how an administrator can control users' ability to execute system operations and to access schema objects by using privileges and roles. The chapter includes:

If you are configured with Trusted Oracle, see the Trusted Oracle7 Server Administrator's Guide.


A privilege is a right to execute a particular type of SQL statement or to access another user's object. Some examples of privileges include

Complete listings of all system and object privileges, as well as instructions for privilege management, are included in the Oracle7 Server Administrator's Guide.

You grant privileges to users so these users can accomplish tasks required for their job. You should grant a privilege only to a user who absolutely requires the privilege to accomplish necessary work. Excessive granting of unnecessary privileges can lead to compromised security. A user can receive a privilege in two different ways:

Because roles allow for easier and better management of privileges, you should normally grant privileges to roles and not to specific users.

There are two distinct categories of privileges:

System Privileges

A system privilege is the right to perform a particular action, or to perform a particular action on a particular type of object. For example, the privileges to create tablespaces and to delete the rows of any table in a database are system privileges. There are over 60 distinct system privileges.

Granting and Revoking System Privileges

You can grant or revoke system privileges to users and roles. If system privileges are granted to roles, the advantages of roles can be used to manage system privileges (for example, roles permit privileges to be made selectively available).

System privileges are granted to or revoked from users and roles using either of the following:

Note: Usually, you should grant system privileges only to administrative personnel and application developers because end users normally do not require the associated capabilities.

Who Can Grant or Revoke System Privileges?

Only users granted a specific system privilege with the ADMIN OPTION or users with the GRANT ANY PRIVILEGE system privilege (typically database or security administrators) can grant or revoke system privileges to other users.

Object Privileges

An object privilege is a privilege or right to perform a particular action on a specific table, view, sequence, procedure, function, or package. For example, the privilege to delete rows from the table DEPT is an object privilege. Depending on the type of object, there are different types of object privileges.

Some schema objects (such as clusters, indexes, triggers, and database links) do not have associated object privileges; their use is controlled with system privileges. For example, to alter a cluster, a user must own the cluster or have the ALTER ANY CLUSTER system privilege.

Object privileges granted for a table, view, sequence, procedure, function, or package apply whether referencing the base object by name or using a synonym. For example, assume there is a table JWARD.EMP with a synonym named JWARD.EMPLOYEE. JWARD issues the following statement:

GRANT SELECT ON emp TO swilliams; 

The user SWILLIAMS can query JWARD.EMP by referencing the table by name or using the synonym JWARD.EMPLOYEE:

SELECT * FROM jward.emp; 
SELECT * FROM jward.employee; 

If you grant object privileges on a table, view, sequence, procedure, function, or package to a synonym for the object, the effect is the same as if no synonym were used For example, if JWARD wanted to grant the SELECT privilege for the EMP table to SWILLIAMS, JWARD could issue either of the following statements:

GRANT SELECT ON emp TO swilliams; 
GRANT SELECT ON employee TO swilliams; 

If a synonym is dropped, all grants for the underlying object remain in effect, even if the privileges were granted by specifying the dropped synonym.

Granting and Revoking Object Privileges

Object privileges can be granted to and revoked from users and roles. If you grant object privileges to roles, you can make the privileges selectively available. Object privileges can be granted to, or revoked from, users and roles using the SQL commands GRANT and REVOKE, respectively.

Who Can Grant Object Privileges?

A user automatically has all object privileges for the objects contained in the schema that corresponds to the user's name -- in other words, the schema the user owns. A user can grant any object privilege on any object he or she owns to any other user or role. If the grant includes the GRANT OPTION (of the GRANT command), the grantee can further grant the object privilege to other users; otherwise, the grantee can only use the privilege but not grant it to other users.

Table Security Topics

The object privileges for tables allow table security at two levels:

Data Manipulation Language Operations The DELETE, INSERT, SELECT, and UPDATE privileges allow the DELETE, INSERT, SELECT, and UPDATE DML operations, respectively, on a table or view (DML operations are those to view or change a table's contents). You should grant these privileges only to users and roles that need to view or manipulate a table's data. For more information on these operations, see the Oracle7 Server SQL Reference.

You can restrict the INSERT and UPDATE privileges for a table to specific columns of the table. With selective INSERT, a privileged user can insert a row, but only with values for the selected columns; all other columns receive NULL or the column's default value. With selective UPDATE, a user can update only specific column values of a row. Selective INSERT and UPDATE privileges are used to restrict a user's access to sensitive data.

For example, if you do not want data entry users to alter the SAL column of the employee table, selective INSERT and/or UPDATE privileges can be granted that exclude the SAL column. Alternatively, a view could satisfy this need for additional security.

Data Definition Language Operations The ALTER, INDEX, and REFERENCES privileges allow DDL operations to be performed on a table. Because these privileges allow other users to alter or create dependencies on a table, you should grant the privileges conservatively. In addition to these privileges, a user attempting to perform a DDL operation on a table may need other system and/or object privileges (for example, to create a trigger on a table, the user requires both the ALTER TABLE object privilege for the table and the CREATE TRIGGER system privilege).

As with the INSERT and UPDATE privileges, the REFERENCES privilege can be granted on specific columns of a table. The REFERENCES privilege enables the grantee to use the table on which the grant is made as a parent key to any foreign keys that the grantee wishes to create in his/her own tables. This action is controlled with a special privilege because the presence of foreign keys restricts the data manipulation and table alterations that can be done to the parent key. A column-specific REFERENCES privilege restricts the grantee to using the named columns, which, of course, must include at least one primary or unique key of the parent table. See Chapter 7, "Data Integrity," for more information about primary keys, unique keys, and integrity constraints.

View Security Topics

The object privileges for views allow various DML operations. Of course, a DML statement performed on a view actually affects the base tables from which the view is derived. DML object privileges for tables can be applied similarly to views.

Privileges Required To Create Views To create a view, you must meet the following requirements:

Increasing Table Security Using Views To use a view, you only require the appropriate privilege for the view itself. You do not require any privileges on the base object(s) underlying the view.

Views are useful for adding two more levels of security for tables:

		CREATE VIEW emp_mgr AS 
		   SELECT ename, empno, mgr FROM emp; 

		CREATE VIEW lowsal AS 
		   SELECT * FROM emp 
		   WHERE sal < 10000; 

		CREATE VIEW own_salary AS 
		   SELECT ename, sal 
		   FROM emp 
		   WHERE ename = USER; 

Procedure Security Topics

The one object privilege for procedures (including standalone procedures and functions, and packages) is EXECUTE. You should grant this privilege only to users who need to execute a procedure.

You can use procedures to add a level of database security. A user requires only the privilege to execute a procedure and no privileges on the underlying objects that a procedure's code accesses. By writing a procedure and granting only the EXECUTE privilege to a user (and not the privileges on the objects referenced by the procedure), the user can be forced to access the referenced objects only through the procedure (that is, the user cannot submit ad hoc SQL statements to the database).

Privileges Needed to Create or Alter a Procedure To create a procedure, a user must have the CREATE PROCEDURE or CREATE ANY PROCEDURE system privilege. To alter a procedure, that is, to manually recompile a procedure, a user must own the procedure or have the ALTER ANY PROCEDURE system privilege.

Additionally, the user who owns the procedure must have the required privileges for the objects referenced in the body of a procedure. To create a procedure, you must have been explicitly granted the necessary privileges (system and/or object) on all objects referenced by the stored procedure; you cannot have obtained the required privileges through roles. This includes the EXECUTE privilege for any procedures that are called inside the stored procedure being created. Triggers also require that privileges to referenced objects be granted explicitly to the trigger owner. Anonymous PL/SQL blocks can use any privilege, whether the privilege is granted explicitly or via a role.

Procedure Execution and Security Domains A user with the EXECUTE privilege for a specific procedure can execute the procedure. A user with the EXECUTE ANY PROCEDURE system privilege can execute any procedure in the database. A user can be granted the privileges to execute procedures via roles.

When you execute a procedure, it operates under the security domain of the user who owns the procedure, regardless of who is executing it. Therefore, a user does not need privileges on the referenced objects to execute a procedure. Because the owner of a procedure must have the necessary object privileges for referenced objects, fewer privileges have to be granted to users of the procedure and tighter control of database access can be obtained.

The current privileges of the owner of a stored procedure are always checked before the procedure is executed. If a necessary privilege on a referenced object is revoked from the owner of a procedure, the procedure cannot be executed by the owner or any other user.

Note: Trigger execution follows these same patterns. The user executes a SQL statement, which he/she is privileged to execute. As a result of the SQL statement, a trigger is fired. The statements within the triggered action temporarily execute under the security domain of the user that owns the trigger.

Packages and Package Objects A user with the EXECUTE privilege for a package can execute any (public) procedure or function in the package, and access or modify the value of any (public) package variable. Specific EXECUTE privileges cannot be granted for a package's constructs. Because of this, you may find it useful to consider two alternatives for establishing security when developing procedures, functions, and packages for a database application. These alternatives are described in the following examples.

Example 1

This example shows four procedures created in the bodies of two packages.

	PROCEDURE hire(...) IS 
			INSERT INTO emp . . . 
		END hire; 
	PROCEDURE fire(...) IS 
			DELETE FROM emp . . . 
		END fire; 
END hire_fire; 
	PROCEDURE give_raise(...) IS 
			UPDATE EMP SET sal = . . . 
		END give_raise; 
	PROCEDURE give_bonus(...) IS 
			UPDATE EMP SET bonus = . . . 
		END give_bonus; 
END raise_bonus; 

Access to execute the procedures is given by granting the EXECUTE privilege for the encompassing package, as in the following statements:

GRANT EXECUTE ON hire_fire TO big_bosses; 
GRANT EXECUTE ON raise_bonus TO little_bosses; 

This method of security for package objects is not discriminatory for any specific object in a package. The EXECUTE privilege granted for the package provides access to all package objects.

Example 2

This example shows four procedure definitions within the body of a single package. Two additional standalone procedures and a package are created specifically to provide access to the procedures defined in the main package.

CREATE PACKAGE BODY employee_changes AS 
	PROCEDURE change_salary(...) IS BEGIN ... END; 
	PROCEDURE change_bonus(...) IS BEGIN ... END; 
	PROCEDURE insert_employee(...) IS BEGIN ... END; 
	PROCEDURE delete_employee(...) IS BEGIN ... END; 
END employee_change; 
	END hire; 
	END fire; 
PACKAGE raise_bonus IS 
	PROCEDURE give_raise(...) AS 
		END give_raise; 
	PROCEDURE give_bonus(...) 
		END give_bonus; 

Using this method, the procedures that actually do the work (the procedures in the EMPLOYEE_CHANGES package) are defined in a single package and can share declared global variables, cursors, on so on. By declaring the top-level procedures HIRE and FIRE, and the additional package RAISE_BONUS, you can indirectly grant selective EXECUTE privileges on the procedures in the main package.

GRANT EXECUTE ON hire, fire TO big_bosses; 
GRANT EXECUTE ON raise_bonus TO little_bosses; 


Oracle provides for easy and controlled privilege management through roles. Roles are named groups of related privileges that you grant to users or other roles. Roles are designed to ease the administration of end-user system and object privileges. However, roles are not meant to be used for application developers, because the privileges to access objects within stored programmatic constructs need to be granted directly. See the section "Data Definition Language Statements and Roles" [*] for more information about restrictions for procedures.

These properties of roles allow for easier privilege management within a database:

Common Uses for Roles

In general, you create a role to serve one of two purposes: to manage the privileges for a database application or to manage the privileges for a user group. Figure 18 - 1 and the sections that follow describe the two uses of roles.

Figure 18 - 1. Common Uses for Roles

Application Roles

You grant an application role all privileges necessary to run a given database application. Then, you grant an application role to other roles or to specific users. An application can have several different roles, with each role assigned a different set of privileges that allow for more or less data access while using the application.

User Roles

You create a user role for a group of database users with common privilege requirements. You manage user privileges by granting application roles and privileges to the user role and then granting the user role to appropriate users.

The Mechanisms of Roles

The functionality of database roles includes the following:

Granting and Revoking Roles

You grant or revoke roles from users or other roles using the following options:

Privileges are granted to and revoked from roles using the same options. Roles can also be granted to and revoked from users using the operating system that executes Oracle.

More detailed instructions on role management are included in the Oracle7 Server Administrator's Guide.

Who Can Grant or Revoke Roles?

Who Can Grant or Revoke Roles?

Who Can Grant or Revoke Roles?

Any user with the GRANT ANY ROLE system privilege can grant or revoke any role to or from other users or roles of the database. You should grant this system privilege conservatively because it is very powerful. Additionally, any user granted a role with the ADMIN OPTION can grant or revoke that role to or from other users or roles of the database. This option allows administrative powers for roles on a selective basis.

Naming Roles

Within a database, each role name must be unique, and no username and role name can be the same. Unlike schema objects, roles are not "contained" in any schema. Therefore, a user who creates a role can be dropped with no effect on the role.

Security Domains of a Role and a User Granted Roles

Each role and user has its own unique security domain. A role's security domain includes the privileges granted to the role plus those privileges granted to any roles that are granted to the role. A user's security domain includes privileges on all objects in the corresponding schema, the privileges granted to the user, and the privileges of roles granted to the user that are currently enabled. A user's security domain also includes the privileges and roles granted to the user group PUBLIC. A role can be simultaneously enabled for one user and disabled for another.

Data Definition Language Statements and Roles

Depending on the statement, a user requires one or more privileges to successfully execute a DDL statement. For example, to create a table, the user must have the CREATE TABLE or CREATE ANY TABLE system privilege. To create a view of another user's table, the creator requires the CREATE VIEW or CREATE ANY VIEW system privilege and either the SELECT privilege for the table or the SELECT ANY TABLE system privilege.

Oracle avoids the dependencies on privileges received via roles by restricting the use of specific privileges in certain DDL statements. The following rules outline these privilege restrictions concerning DDL statements:

The following example further clarifies the permitted and restricted uses of privileges received via roles:


Assume that a user

Given these directly and indirectly granted privileges:

Predefined Roles

The roles CONNECT, RESOURCE, DBA, EXP_FULL_DATABASE, and IMP_FULL_DATABASE are defined automatically for Oracle databases. These roles are provided for backward compatibility to earlier versions of Oracle and can be modified in the same manner as any other role in an Oracle database.

The Operating System and Roles

In some environments, you can administer database security using the operating system. The operating system can be used to manage the grants (and revokes) of database roles and/or manage their password authentication.

Additional Information: This capability might not be available on all operating systems. See your operating system-specific Oracle documentation for details on managing roles through the operating system.

Roles in a Distributed Environment

When you use roles in a distributed database environment, you must make sure that all needed roles are set as the default roles for a distributed session. You cannot enable roles when connecting to a remote database from within a local database session. For example, you cannot execute a remote procedure which attempts to enable a role at the remote site. To use roles in a distributed environment, you must make the required roles the default role for the remote session. For more information about distributed database environments, see Oracle7 Server Distributed Systems, Volume I.

Go to previous file in sequence Go to next file in sequence
Prev Next
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index