출처 : 오라클 사이트
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_9013.htm#SQLRF01603
GRANT
Purpose
Use the GRANT statement to grant:
-
System privileges to users and roles.
-
Roles to users and roles. Both privileges and roles are either local, global, or external. Table 18-1 lists the system privileges (organized by the database object operated upon). Table 18-2 lists Oracle Database predefined roles.
-
Object privileges for a particular object to users, roles, and PUBLIC. Table 18-3 summarizes the object privileges that you can grant on each type of object. Table 18-4 lists object privileges and the operations that they authorize.
Notes on Authorizing Database Users You can authorize database users through means other than the database and the GRANT statement.
-
Many Oracle Database privileges are granted through supplied PL/SQL and Java packages. For information on those privileges, please refer to the documentation for the appropriate package.
-
Some operating systems have facilities that let you grant roles to Oracle Database users with the initialization parameter OS_ROLES. If you choose to grant roles to users through operating system facilities, then you cannot also grant roles to users with the GRANT statement, although you can use the GRANT statement to grant system privileges to users and system privileges and roles to other roles.
Additional Topics
Prerequisites
To grant a system privilege, you must either have been granted the system privilege with the ADMIN OPTION or have been granted the GRANT ANY PRIVILEGE system privilege.
To grant a role, you must either have been granted the role with the ADMIN OPTION or have been granted the GRANT ANY ROLE system privilege, or you must have created the role.
To grant an object privilege, you must own the object, or the owner of the object must have granted you the object privileges with the GRANT OPTION, or you must have been granted the GRANT ANY OBJECT PRIVILEGE system privilege. If you have the GRANT ANY OBJECT PRIVILEGE, then you can grant the object privilege only if the object owner could have granted the same object privilege. In this case, the GRANTOR column of the DBA_TAB_PRIVS view displays the object owner rather than the user who issued the GRANT statement.
Syntax
grant::=
Description of the illustration grant.gif
(grant_system_privileges::=, grant_object_privileges::=)
grant_system_privileges::=
Description of the illustration grant_system_privileges.gif
(grantee_clause ::=)
grant_object_privileges::=
Description of the illustration grant_object_privileges.gif
(on_object_clause ::=, grantee_clause ::=)
on_object_clause ::=
Description of the illustration on_object_clause.gif
grantee_clause ::=
Description of the illustration grantee_clause.gif
Semantics
grant_system_privileges
Use these clauses to grant system privileges.
system_privilege
Specify the system privilege you want to grant. Table 18-1 lists the system privileges, organized by the database object operated upon.
-
If you grant a privilege to a user, then the database adds the privilege to the user's privilege domain. The user can immediately exercise the privilege.
-
If you grant a privilege to a role, then the database adds the privilege to the privilege domain of the role. Users who have been granted and have enabled the role can immediately exercise the privilege. Other users who have been granted the role can enable the role and exercise the privilege.
-
If you grant a privilege to PUBLIC, then the database adds the privilege to the privilege domains of each user. All users can immediately perform operations authorized by the privilege.
Oracle Database provides the ALL PRIVILEGES shortcut for granting all the system privileges listed in Table 18-1, except the SELECT ANY DICTIONARY privilege.
role
Specify the role you want to grant. You can grant an Oracle Database predefined role or a user-defined role. Table 18-2 lists the predefined roles.
-
If you grant a role to a user, then the database makes the role available to the user. The user can immediately enable the role and exercise the privileges in the privilege domain of the role.
-
If you grant a role to another role, then the database adds the privilege domain of the granted role to the privilege domain of the grantee role. Users who have been granted the grantee role can enable it and exercise the privileges in the granted role's privilege domain.
-
If you grant a role to PUBLIC, then the database makes the role available to all users. All users can immediately enable the role and exercise the privileges in the privilege domain of the role.
IDENTIFIED BY Clause
Use the IDENTIFIED BY clause to specifically identify an existing user by password or to create a nonexistent user. This clause is not valid if the grantee is a role or PUBLIC. If the user specified in the grantee_clause does not exist, then the database creates the user with the password and with the privileges and roles specified in this clause.
See Also:
CREATE USER for restrictions on usernames and passwords
WITH ADMIN OPTION
Specify WITH ADMIN OPTION to enable the grantee to:
-
Grant the role to another user or role, unless the role is a GLOBAL role
-
Revoke the role from another user or role
-
Alter the role to change the authorization needed to access it
-
Drop the role
If you grant a system privilege or role to a user without specifying WITH ADMIN OPTION, and then subsequently grant the privilege or role to the user WITH ADMIN OPTION, then the user has the ADMIN OPTION on the privilege or role.
To revoke the ADMIN OPTION on a system privilege or role from a user, you must revoke the privilege or role from the user altogether and then grant the privilege or role to the user without the ADMIN OPTION.
grantee_clause
TO grantee_clause identifies users or roles to which the system privilege, role, or object privilege is granted.
Restriction on Grantees A user, role, or PUBLIC cannot appear more than once in TO grantee_clause.
PUBLIC Specify PUBLIC to grant the privileges to all users.
Restrictions on Granting System Privileges and Roles Privileges and roles are subject to the following restrictions:
-
A privilege or role cannot appear more than once in the list of privileges and roles to be granted.
-
You cannot grant a role to itself.
-
You cannot grant a role IDENTIFIED GLOBALLY to anything.
-
You cannot grant a role IDENTIFIED EXTERNALLY to a global user or global role.
-
You cannot grant roles circularly. For example, if you grant the role banker to the role teller, then you cannot subsequently grant teller to banker.
grant_object_privileges
Use these clauses to grant object privileges.
object_privilege
Specify the object privilege you want to grant. You can specify any of the values shown in Table 18-3. See also Table 18-4.
Restriction on Object Privileges A privilege cannot appear more than once in the list of privileges to be granted.
ALL [PRIVILEGES]
Specify ALL to grant all the privileges for the object that you have been granted with the GRANT OPTION. The user who owns the schema containing an object automatically has all privileges on the object with the GRANT OPTION. The keyword PRIVILEGES is provided for semantic clarity and is optional.
column
Specify the table or view column on which privileges are to be granted. You can specify columns only when granting the INSERT, REFERENCES, or UPDATE privilege. If you do not list columns, then the grantee has the specified privilege on all columns in the table or view.
For information on existing column object grants, query the USER_, ALL_, or DBA_COL_PRIVS data dictionary view.
on_object_clause
The on_object_clause identifies the object on which the privileges are granted. Directory schema objects and Java source and resource schema objects are identified separately because they reside in separate namespaces.
If you can make this grant only because you have the GRANT ANY OBJECT PRIVILEGE system privilege--that is, you are not the owner of object, nor do you have object_privilege on object WITH GRANT OPTION--then the effect of this grant is that you are acting on behalf of the object owner. The *_TAB_PRIVS data dictionary views will reflect that this grant was made by the owner of object.
WITH GRANT OPTION
Specify WITH GRANT OPTION to enable the grantee to grant the object privileges to other users and roles.
Restriction on Granting WITH GRANT OPTION You can specify WITH GRANT OPTION only when granting to a user or to PUBLIC, not when granting to a role.
WITH HIERARCHY OPTION
Specify WITH HIERARCHY OPTION to grant the specified object privilege on all subobjects of object, such as subviews created under a view, including subobjects created subsequent to this statement.
This clause is meaningful only in combination with the SELECT object privilege.
object Specify the schema object on which the privileges are to be granted. If you do not qualify object with schema, then the database assumes the object is in your own schema. The object can be one of the following types:
-
Table, view, or materialized view
-
Sequence
-
Procedure, function, or package
-
User-defined type
-
Synonym for any of the preceding items
-
Directory, library, operator, or indextype
-
Java source, class, or resource
You cannot grant privileges directly to a single partition of a partitioned table.
DIRECTORY directory_name Specify a directory schema object on which privileges are to be granted. You cannot qualify directory_name with a schema name.
JAVA SOURCE | RESOURCE The JAVA clause lets you specify a Java source or resource schema object on which privileges are to be granted.
Listings of System and Object Privileges
Note:
When you grant a privilege on
ANY object, such as
CREATE ANY CLUSTER, the result is determined by the value of the
O7_DICTIONARY_ACCESSIBILITY initialization parameter. By default, this parameter is set to
FALSE, so that
ANY privileges give the grantee access to that type of object in all schemas except the
SYS schema. If you set
O7_DICTIONARY_ACCESSIBILITY to
TRUE, then the
ANY privileges also give the grantee access, in the
SYS schema, to all objects except Oracle Scheduler objects. For security reasons, Oracle recommends that you use this setting only with great caution.
Note 1: Oracle Database treats a Java class, source, or resource as if it were a procedure for purposes of granting object privileges.
Note 2: Job scheduler objects are created using the DBMS_SCHEDULER package. After these objects are created, you can grant the EXECUTE object privilege on job scheduler classes and programs. You can grant ALTER privilege on job scheduler jobs, programs, and schedules.
Note 3: The DELETE, INSERT, and UPDATE privileges can be granted only to updatable materialized views.
Examples
Granting a System Privilege to a User: Example To grant the CREATE SESSION system privilege to the sample user hr, allowing hr to log on to Oracle Database, issue the following statement:
GRANT CREATE SESSION
TO hr;
Granting System Privileges to a Role: Example The following statement grants appropriate system privileges to a data warehouse manager role, which was created in the "Creating a Role: Example":
GRANT
CREATE ANY MATERIALIZED VIEW
, ALTER ANY MATERIALIZED VIEW
, DROP ANY MATERIALIZED VIEW
, QUERY REWRITE
, GLOBAL QUERY REWRITE
TO dw_manager
WITH ADMIN OPTION;
The dw_manager privilege domain now contains the system privileges related to materialized views.
Granting a Role with the Admin Option: Example To grant the dw_manager role with the ADMIN OPTION to the sample user sh, issue the following statement:
GRANT dw_manager
TO sh
WITH ADMIN OPTION;
User sh can now perform the following operations with the dw_manager role:
-
Enable the role and exercise any privileges in the privilege domain of the role, including the CREATE MATERIALIZED VIEW system privilege
-
Grant and revoke the role to and from other users
-
Drop the role
Granting Object Privileges to a Role: Example The following example grants the SELECT object privileges to a data warehouse user role, which was created in the "Creating a Role: Example":
GRANT SELECT ON sh.sales TO warehouse_user;
Granting a Role to a Role: Example The following statement grants the warehouse_user role to the dw_manager role. Both roles were created in the "Creating a Role: Example":
GRANT warehouse_user TO dw_manager;
The dw_manager role now contains all of the privileges in the domain of the warehouse_user role.
Granting an Object Privilege on a Directory: Example To grant READ on directory bfile_dir to user hr, with the GRANT OPTION, issue the following statement:
GRANT READ ON DIRECTORY bfile_dir TO hr
WITH GRANT OPTION;
Granting Object Privileges on a Table to a User: Example To grant all privileges on the table oe.bonuses, which was created in "Merging into a Table: Example", to the user hr with the GRANT OPTION, issue the following statement:
GRANT ALL ON bonuses TO hr
WITH GRANT OPTION;
The user hr can subsequently perform the following operations:
Granting Object Privileges on a View: Example To grant SELECT and UPDATE privileges on the view emp_view, which was created in "Creating a View: Example", to all users, issue the following statement:
GRANT SELECT, UPDATE
ON emp_view TO PUBLIC;
All users can subsequently query and update the view of employee details.
Granting Object Privileges to a Sequence in Another Schema: Example To grant SELECT privilege on the customers_seq sequence in the schema oe to the user hr, issue the following statement:
GRANT SELECT
ON oe.customers_seq TO hr;
The user hr can subsequently generate the next value of the sequence with the following statement:
SELECT oe.customers_seq.NEXTVAL
FROM DUAL;
Granting Multiple Object Privileges on Individual Columns: Example To grant to user oe the REFERENCES privilege on the employee_id column and the UPDATE privilege on the employee_id, salary, and commission_pct columns of the employees table in the schema hr, issue the following statement:
GRANT REFERENCES (employee_id),
UPDATE (employee_id, salary, commission_pct)
ON hr.employees
TO oe;
The user oe can subsequently update values of the employee_id, salary, and commission_pct columns. User oe can also define referential integrity constraints that refer to the employee_id column. However, because the GRANT statement lists only these columns, oe cannot perform operations on any of the other columns of the employees table.
For example, oe can create a table with a constraint:
CREATE TABLE dependent
(dependno NUMBER,
dependname VARCHAR2(10),
employee NUMBER
CONSTRAINT in_emp REFERENCES hr.employees(employee_id) );
The constraint in_emp ensures that all dependents in the dependent table correspond to an employee in the employees table in the schema hr.
VistaUACMaker.zip
