ROLES AND PRIVILEGES IN ORACLE.pdf

ADMINSTRING ROLES AND PRIVILEGES IN ORACLE

ROLES AND PRIVILEGES Roles are grouping of SYSTEM PRIVILEGES AND/OR OBJECT PRIVILEGES. Roles are most helpful to simply allocation of set of privileges. When large number of users need the same system and or object privileges, you can create the role then grant system and/or object privileges. Managing and controlling privileges is much easier when using roles. You can create roles, grant system and object privilege to the roles and grant roles to the user. CONNECT, RESOURCE & DBA roles are pre-defined roles. These are created by oracle when the database is created. You can grant these roles when you create a user.

SYS> select * from ROLE_SYS_PRIVS where role='CONNECT'; ROLE

PRIVILEGE

ADM

--------- ------------------ ---CONNECT

CREATE SESSION

NO

SYS> select * from ROLE_SYS_PRIVS where role='RESOURCE'; ROLE

PRIVILEGE

ADM

------------------------------ ---------------------------------------- --RESOURCE

CREATE SEQUENCE

NO

RESOURCE

CREATE TRIGGER

NO

RESOURCE

CREATE CLUSTER

NO

RESOURCE

CREATE PROCEDURE

NO

RESOURCE

CREATE TYPE

NO

RESOURCE

CREATE OPERATOR

NO

RESOURCE

CREATE TABLE

NO

RESOURCE

CREATE INDEXTYPE

NO

8 rows selected. CREATE SESSION privilege is used to a user connect to the oracle database. Database users (NON DBA’s) should NOT be granted privs with ANY keyword like CREATE ANY TABLE, ALTER/SELECT/INSERT/UPDATE/DELETE/DROP ANY TABLE, CREATE/ALTER/DROP ANY INDEX and many more. When you grant RESOURCE role to the user, that the user can get "UNLIMITED TABLESPACE" privilege. RESOURCE role comes with unlimited tablespace privilege, even it cannot be displayed directly. SYS> select * from ROLE_SYS_PRIVS where role = 'DBA'; ROLE

PRIVILEGE

ADM

------------------------------ ---------------------- --DBA

CREATE SESSION

YES

DBA

ALTER SESSION

YES

DBA

DROP TABLESPACE

YES

DBA

BECOME USER

YES

DBA

DROP ROLLBACK SEGMENT

YES

.. ...

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu


DBA role has all SYSTEM PRIVILEGE and also this role comes WITH ADMIN OPTION. If a privilege with admin option, the grantee can grant granted privilege to other users. Getting confused? SYS> grant create any index to rose; Grant succeeded. SYS> grant create any table to rose WITH ADMIN OPTION; Grant succeeded. SYS> select * from dba_sys_privs where grantee in('ROSE'); GRANTEE

PRIVILEGE

ADM

---------------------------- ---------------------- ---ROSE

CREATE ANY INDEX

NO

ROSE

CREATE ANY TABLE

YES

ROSE> grant create any table to sony; Grant succeeded. ROSE> grant create any index to sony; grant create any index to sony * ERROR at line 1: ORA-01031: insufficient privileges A DBA role does NOT include startup & shutdown the databases. The DBA role enables user to perform administrative functions are creating users & granting privileges to the users, creating roles & granting privileges to the roles, creating & dropping schema objects and many more. WHAT IS PRIVILEGE Privilege is special right or permission. Privileges are granted to perform operations in a database such as executing an SQL statements or to access another user’s objects. Privileges can be assigned to a user or a role. Privileges are given to users with GRANT command and taken away with REVOKE command. In oracle, there are two distinct type of privileges. SYSTEM PRIVILEGES & SCHEMA OBJECT PRIVILEGES. SYSTEM privileges are NOT directly related to any specific object or schema. OBJECT privileges are directly related to specific object or schema. GRANT



REVOKE 

To assign privileges or roles to a user, use GRANT command. To remove privileges or roles from a user, use REVOKE command.

SYSTEM PRIVILEGES SYSTEM PRIVILEGE is granted by DBA’s. It allows user to perform standard database administrator level activities such as creating, altering, dropping and managing database objects. SYSTEM PRIVILEGE is very most powerful and it should be granted to trusted users of the database. Some of the system level privileges are related to administrative actions like ALTER DATABASE, ALTER SESSION, ALTER SYSTEM, CREATE USER, ALTER USER, DROP USER, CREATE TABLESPACE and more...



SYSTEM PRIVILEGE can be displayed with following query. SYS> SELECT NAME FROM SYSTEM_PRIVILEGE_MAP; Two type of users can GRANT & REVOKE SYSTEM PRIVILEGES to others. User who have been granted specific SYSTEM PRIVILEGE WITH ADMIN OPTION. User who have been granted GRANT ANY PRIVILEGE. Most powerful SYSTEM PRIVILEGES are SYSDBA and SYSOPER. You cannot grant this privilege to a role and cannot use WITH ADMIN OPTION. SYSOPER

SYSDBA

ALTER DATABASE BEGIN BACKUP AND END BACKUP MOUNT AND DISMOUNT THE DATABASE OPEN AND CLOSE THE DATABASE ALTER DATABASE ARCHIVELOG

ALL SYSOPER PRIVILEGES

+

CREATE DATABASE COMMAND

+

ALL SYSTEM PRIVLEGES WITH ADMIN OPTION

RECOVERY OPERATIONS RESRTRICTED SESSION

SYSTEM PRIVILEGES can be granted WITH ADMIN OPTION. You can GRANT and REVOKE system privileges to the users and roles. GRANTING & REVOKING SYSTEM LEVEL PRIVILEGES SYS> GRANT create table to sham; SYS> GRANT create view, create synonym to rose; SYS> GRANT create sequence, create trigger to sham, rose; SYS> GRANT create procedure to sham, rose WITH ADMIN OPTION; SYS> REVOKE create view, create synonym from sham; VIEWS FOR SYSTEM PRIVILEGES & ROLES SESSION_PRIVS

USER_SYS_PRIVS

ALL_SYS_PRIVS

ROLE_SYS_PRIVS

DBA_SYS_PRIVS

SYSTEM_PRIVILEGE_MAP

ROLE_ROLE_PRIVS

ROLE_TAB_PRIVS

SESSION_ROLES

DBA_ROLES

USER_ROLE_PRIVS

ROLE_ROL_PRIVS

OBJECT PRIVILEGES Object privilege is the permission to perform certain action on a specific schema objects, including tables, views, sequence, procedures, functions, packages and more. Object privilege grants always include the name of the object for which privilege is granted to whom. Object level privileges are granted by owners. An object owner has all object privileges for that object and those privileges cannot be revoked. Generally object level privileges provides access to database objects. An application developer may have the following system privilege. CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE PROCEDURE, CREATE TRIGGER OBJECT PRIVILEGES can be granted WITH GRANT OPTION. You can grant or revoke system privileges to users and roles.



GRANTING & REVOKING OBJECT LEVEL PRIVILEGES SHAM> grant select on EMP to SCOTT; SHAM> grant update (mob_no) on EMP to SCOTT; SHAM> grant select, insert on EMP to SCOTT; SHAM> grant update, delete on EMP to SCOTT; SHAM> grant all on EMP to SCOTT;

# Grant all table level privileges

SHAM> grant references on EMP to SCOTT; SHAM> grant select on EMP to SCOTT with GRANT OPTION; SHAM> revoke update on EMP from SCOTT; SHAM> revoke select, insert, delete on EMP from SCOTT; SHAM> revoke all on EMP from SCOTT; SHAM> revoke references on EMP from SCOTT; SHAM> revoke references on EMP from SCOTT CASCADE CONSTRAINTS; PUBLIC MEANS If a privilege has been granted to PUBLIC, all users in the database can use it. Public acts like a ROLE, sometimes acts like a USER. SHAM> conn / as sysoper Connected. PUBLIC> SHOW USER; USER IS “PUBLIC” The catalog table user$ contains both ROLES and USERS. If Column TYPE# value 1= USER and 0 = ROLE SYS> select user#, name, type# from user$ order by 1; USER#

NAME

TYPE#

------ ----------------- ---------0

SYS

1

1

PUBLIC

0

2

CONNECT

0

3

RESOURCE

0

4

DBA

0

5

SYSTEM

1

SCOTT

1

84 .. ...

PUBLIC is accessible to every database user. Privileges and roles are granted to public and accessible to every database user. You can revoke roles and privileges from the PUBLIC. SHAM> grant select on EMP to PUBLIC; Grant succeeded. SHAM> select * from USER_PRIVS_MADE; GRANTEE TABLE_NAME GRANTOR PRIVILEGE GRA HIE ------------ ---------- ------------ ------------ --- --PUBLIC EMP SHAM SELECT NO NO



SHAM> revoke select on EMP from PUBLIC; Revoke succeeded. SHAM> select *

from USER_TAB_PRIVS_MADE;

no rows selected

SYS> grant create session to PUBLIC; Grant succeeded. SYS> select * from DBA_SYS_PRIVS where grantee in('PUBLIC'); GRANTEE

PRIVILEGE

ADM

------------------------------ ---------------------------------------- --PUBLIC

CREATE SESSION

NO

Now newly created user can connect to the database without giving ‘CREATE SESSION’ privilege but user can get the privilege from the public role. SYSTEM PRIVILEGES CREATE PRIVILEGES

CREATE ANY PRIVILEGES

ALTER PRIVILEGES

OTHER SYSTEM PRIVILEGES

CREATE SESSION

CREATE ANY TABLE

ALTER DATABASE

AUDIT ANY

CREATE TABLE

CREATE ANY VIEW

ALTER SESSION

LOCK ANY TABLE

CREATE USER

CREATE ANY TRIGGER

ALTER SYSTEM

COMMENT ANY TABLE

CREATE VIEW

CREATE ANY SEQUENCE

ALTER USER

EXECUTE ANY PROCEDURE

CREATE TRIGGER

CREATE ANY PROCEDURE

ALTER PROFILE

SELECT ANY SEQUENCE

CREATE SEQUENCE

DROP ANY PRIVILEGES

ALTER TABLESPACE

SELECT ANY TABLE

CREATE PROCEDURE

DROP ANY ROLE

ALTER ANY PRIVILEGE

INSERT ANY TABLE

CREATE PROFILE

DROP ANY SEQUENCE

ALTER ANY ROLE

UPDATE ANY TABLE

CREATE TABLESPACE

DROP ANY SYNONYM

ALTER ANY PROCEDURE

DELETE ANY TABLE

CREATE DATABASE LINK

DROP ANY TRIGGER

ALTER ANY TRIGGER

UNLIMTED TABLESPACE

CREATE PUBLIC SYNONYM

DROP ANY TABLE

ALTER ANY SEQUENCE

GRANT ANY PRIVILEGE

DROP PRIVILEGE

DROP ANY VIEW

ALTER ANY TABLE

GRANT ANY ROLE

DROP USER

DROP ANY INDEX

ALTER ANY INDEX

RESTRICTED SESSION

DROP PROFILE

DROP PUBLIC SYNONYM

ALTER ANY CLUSTER

FORCE TRANSACTION

DROP TABLESPACE

DROP ANY DIRECTORY

ALTER ANY INDEXTYPE

FLASHBACK ANY TABLE

OBJECT PRIVILEGES TABLES

VIEWS

DIRECTORIES

MATERIALIZED VIEWS

SELECT

SELECT

READ

SELECT

INSERT

INSERT

WRITE

INSERT

UPDATE

UPDATE

AUDIT

UPDATE

DELETE

DELETE

INDEX TYPES

DELETE

ALTER

REFERENCES

EXECUTE

REFERENCES

SEQUENCES

PACKAGES PROCEDURES AND FUNCTIONS

ALL

SELECT AND ALTER

EXECUTE , DEBUG

NOTE: Is there DROP TABLE PRIVILEGE in oracle?

NO. DROP TABLE is NOT a PRIVILEGE.



VIEWS FOR OBJECT LEVEL PRIVILEGES DBA_TAB_PRIVS

ALL_TAB_PRIVS

USER_TAB_PRIVS

DBA_COL_PRIVS

ALL_COL_PRIVS

USER_COL_PRIVS

SESSION_PRIVS

ALL_TAB_PRIVS_MADE

USER_TAB_PRIVS_MADE

ALL_TAB_PRIVS_RECD

USER_TAB_PRIVS_RECD

ALL_COL_PRIVS_MADE

USER_COL_PRIVS_MADE

ALL_COL_PRIVS_RECD

USER_COL_PRIVS_RECD

WITH GRANT AND WITH ADMIN OPTION SYSTEM PRIVILEGE can be granted WITH ADMIN OPTION.

(SELECT, INSERT, UPDATE

OBJECT PRIVILEGE can be granted WITH GRANT OPTION.

(CREATE SESSION, CREATE TABLE ...

1) WITH ADMIN OPTION :

SYSDBA --- A --- B -- C

2) WITH GRANT OPTION :

SYSDBA --- A --- B -- C

...

Let’s start WITH ADMIN OPTION: SYS> grant create session to a WITH ADMIN OPTION; Grant succeeded. SYS> select * from dba_sys_privs where grantee in('A'); GRANTEE PRIVILEGE ADM ------------------------------ ---------------------------------------- --A CREATE SESSION YES

A> grant create session to b WITH ADMIN OPTION; Grant succeeded. B> grant create session to c WITH ADMIN OPTION; Grant succeeded. C> revoke creation session from B; Revoke succeeded. C> revoke creation session from A; Revoke succeeded. A> grant create session to B WITH ADMIN OPTION; grant create session to B WITH ADMIN OPTION. * ERROR at line 1: ORA-01031: insufficient privileges

SYS> select * from dba_sys_privs where grantee in('A','B','C'); GRANTEE PRIVILEGE ADM ------------------------------ ---------------------------------------- --C CREATE SESSION YES



WITH ADMIN OPTION : When a user is granted a system privilege, (the grantor  typically a DBA) allows the grantee (who is receiving the privilege) to grant the same privilege to others WITH ADMIN OPTION. If you revoke a SYSTEM PRIVILEGE from a user, it has NO IMPACT on GRANTS that user has made. In this case, suppose all three users has the same privilege. If a revokes the privilege from b, It will NOT affect c. Still c has the privilege. Let’s start WITH GRANT OPTION: SHAM -- ROSE -- SCOTT -- PUBLIC -- ALL USERS

SHAM> grant select on EMP to ROSE WITH GRANT OPTION; Grant succeeded. SHAM> select * from user_tab_privs; GRANTEE

OWNER

TABLE_NAME

GRANTOR

PRIVILEGE

GRA HIE

--------------- --------------- --------------- ------------ --------------- --- --ROSE

SHAM

EMP

SHAM

SELECT

YES NO

PRIVILEGE

GRA HIE

ROSE> grant select on SHAM.EMP to SCOTT WITH GRANT OPTION; Grant succeeded. ROSE> select * from user_tab_privs; GRANTEE

OWNER

TABLE_NAME

GRANTOR

--------------- --------------- --------------- ------------ --------------- --- --SCOTT

SHAM

EMP

ROSE

SELECT

YES NO

ROSE

SHAM

EMP

SHAM

SELECT

YES NO

SCOTT> grant select on SHAM.EMP to PUBLIC WITH GRANT OPTION; Grant succeeded. SCOTT> select * from user_tab_privs; GRANTEE

OWNER

TABLE_NAME

GRANTOR

PRIVILEGE

GRA HIE

--------------- --------------- --------------- ------------ --------------- --- --PUBLIC

SHAM

EMP

SCOTT

SELECT

YES NO

SCOTT

SHAM

EMP

ROSE

SELECT

YES NO

SONY> select * from sham.emp; .. ... SONY> create view emp_view as select * from sham.emp; View created. SONY> select * from emp_view; ...



SONY> select * from user_tab_privs; no rows selected SONY can access user sham.emp table because SELECT PRIVILEGE given to ‘PUBLIC’. So that sham.emp is available to everyone of the database. SONY has created a view EMP_VIEW based on sham.emp SHAM> select * from user_tab_privs; GRANTEE

OWNER

TABLE_NAME

GRANTOR

PRIVILEGE

GRA HIE

--------------- --------------- --------------- ------------ --------------- --- --PUBLIC

SHAM

EMP

SCOTT

SELECT

YES NO

SCOTT

SHAM

EMP

ROSE

SELECT

YES NO

ROSE

SHAM

EMP

SHAM

SELECT

YES NO

SHAM> revoke select on emp from public; revoke select on emp from public * ERROR at line 1: ORA-01927: cannot REVOKE privileges you did not grant SHAM> revoke select on emp from scott; revoke select on emp from scott * ERROR at line 1: ORA-01927: cannot REVOKE privileges you did not grant SHAM> revoke select on EMP from ROSE; Revoke succeeded. SHAM> select * from user_tab_privs; no rows selected. WITH GRANT OPTION: Here you can see SHAM can revoke the privilege from ROSE but NOT from SCOTT and PUBLIC, because OBJECT PRIVILEGE WITH GRANT OPTION implies that we can revoke those privilege from the grantee to whom it was granted directly. As you can see, although we revoked the select privilege only from user ROSE, automatically SELECT privilege revoked from SCOTT and PUBLIC, because a "Cascading Revoke" occurred. If you revoke OBJECT PRIVILEGE from a user, that privilege also revoked to whom it was granted. RESOURCE ROLE Let’s talk about RESOURCE role. You can NOT grant UNLIMITED TABLESPACE privilege directly. However, if you grant a user RESOURCE or DBA role, the user then also has the UNLIMITED TABLESPACE privilege. SYS> create user styris identified by styris default tablespace TBS1 quota 1024m on TBS1; User created. SYS> grant connect, resource to styris; Grant succeeded.



SYS> select * from dba_role_privs where grantee in('STYRIS'); GRANTEE

GRANTED_ROLE

ADMIN_OPTION

DEF

--------------- ------------------------------ --------------- --STYRIS

RESOURCE

NO

YES

STYRIS

CONNECT

NO

YES

SYS> select * from dba_sys_privs where grantee in('STYRIS'); GRANTEE

PRIVILEGE

ADMIN_OPTION

--------------- ------------------------------ --------------STYRIS

UNLIMITED TABLESPACE

NO

If you grant RESOURCE role to the user, this privilege overrides all explicit tablespace quotas. The UNLIMITED TABLESPACE system privilege lets the user allocate as much space in any tablespaces that make up the database. ALLOCATE QUOTA ON TBS2 & TBS3 FOR USER STYRIS SYS> alter user styris quota 100m on TBS2; User altered. SYS> alter user styris quota unlimited on TBS3; User altered. SYS> select * from dba_ts_quotas where username='STYRIS'; TABLESPACE_N USERNAME

BYTES

MAX_BYTES

BLOCKS MAX_BLOCKS DRO

------------ ------------ ---------- ---------- ---------- ---------- --TBS1

STYRIS

0 1073741824

0

131072 NO

TBS2

STYRIS

0

104857600

0

12800 NO

TBS3

STYRIS

0

-1

0

-1 NO

Quota is the amount of space allocated to a user in a tablespace. In dba_ts_quotas view, MAXBYTES column value of -1 indicates UNLIMITED, means that user can use as much space in that tablespace. CREATING TABLES IN DIFFERENT TABLESPACES STYRIS> create table tab2 tablespace TBS1 as select * from tab1; Table created. STYRIS> create table tab2 tablespace USERS as select * from tab1; Table created. USer (styris) has created table in USERS tablespace but never allocated QUOTA on users tablespace. using below query you can find size of the objects and from the user. SYS> SELECT tablespace_name, segment_type, COUNT(*), SUM(bytes)/1024/1024 MB FROM dba_segments WHERE owner = 'STYRIS' GROUP BY tablespace_name, segment_type ORDER BY 1, 2 DESC; ...



So I recommend that schemas use the direct privileges (create table, create trigger, etc) and allocate a tablespace quota directly, instead of granting the RESOURCE role. We should be very careful when revoking UNLIMITED TABLESPACE. When the UNLIMITED TABLESPACE privilege is revoked from a user, it also revokes all granted quotas on any individual tablespace from the user. In other words, after revoking this privilege from a user, the user won’t have any quota on any tablespace at all: BEFORE REVOKE SYS> select * from dba_ts_quotas where username='STYRIS'; TABLESPACE

USERNAME

BYTES

MAX_BYTES

BLOCKS MAX_BLOCKS DRO

------------ ------------ ---------- ---------- ---------- ---------- --TBS1

STYRIS

0 1073741824

0

131072 NO

TBS2

STYRIS

0

104857600

0

12800 NO

TBS3

STYRIS

0

-1

0

-1 NO

Quota: On TBS1 user has 1024 MB, on TBS2 user has 100 MB. -1 indicates Unlimited Quota on TBS3 AFTER REVOKE SYS> revoke unlimited tablespace from STYRIS'; Revoke succeeded. SYS> select * from dba_ts_quotas where username='STYRIS'; no rows selected Is everything fine now? No. When the user tries to create a new segment or extend an existing one, you will get following error. STYRIS> create table ... ERROR at line 1: ORA-01536: space quota exceeded for tablespace ... As a DBA finally grant quotas on tablespaces that you have to desire. ROLES Roles are group of privileges under a single name. Those privileges are assigned to users through ROLES. When you adding or deleting a privilege from a role, all users and roles that are assigned that role automatically receive or lose that privilege. Assigning password to role is optional. Whenever you create a role that is NOT IDENTIFIED or IDENTIFIED EXTERNALLY or BY PASSWORD, then oracle grants you the role WITH ADMIN OPTION. If you create a role IDENTIFIED GLOBALLY, then the database does NOT grant you the role. If you omit both NOT IDENTIFIED/IDENTIFIED clause then default goes to NOT IDENTIFIED clause. NOT IDENTIFIED CLAUSE NOT IDENTIFIED clause indicates that this role is authorized by the database and no password is required to enable the role. .



SYS> create role ; SYS> create role oradev; SYS> create role NOT IDENTIFIED; SYS> create role oratest NOT IDENTIFIED; IDENTIFIED BY PASSWORD CLAUSE IDENTIFIED BY clause indicates that a role must be authorized by the specified method. In our case the specific method is password. Followed by Identified By clause we have our password. SYS> create role identified by ; SYS> create role orcldev identified by devdb; First the DBA must create a role. Then the DBA can assign privileges to the role then grant the role to multiple users or any roles. CREATE A ROLE SYS> create role orcldev IDENTIFIED BY devdb; Role created. GRANTING SYSTEM PRIVILEGES TO A ROLE SYS> GRANT create table, create view, create synonym, create sequence, create trigger to orcldev; Grant succeeded GRANT A ROLE TO USERS SYS> grant to ; SYS> grant orcldev to sony, scott; Grant succeeded. ACTIVATE A ROLE SCOTT> set role identified by ; SCOTT> set role orcldev identified by devdb; TO DISABLING ALL ROLE SCOTT> set role none; GRANT A PRIVILEGE SYS> grant to ; SYS> grant create any table to orcldev; REVOKE A PRIVILEGE SYS> grant from ; SYS> revoke create any table from orcldev;



TO SET ROLE AS DEFAULT ROLE By default role assigned to users are default roles. This means that roles does NOT need to be explicitly enabled with set role. A default role is always enabled for the current session at that time of user logon. SYS> alter user default role ; SYS> create role r1; Role created. SYS> create role r2; Role created. SYS> create role r3; Role created. SYS> grant r1, r2, r3 to maya; Grant succeeded. SYS> alter user maya default role r1; User altered. SYS> alter user maya default role r1; User altered. USER MAYA LOGON SYS> conn maya/maya Connected. MAYA> select * from session_roles; ROLE ------------R1 MAYA> set role all; Role set. MAYA> select * from session_roles; ROLE ------------R1 R3 R2 If you define a role as a non-default role to a user, it must be explicitly enabled. SET ALL ROLES ASSIGNED TO MAYA AS DEFAULT

SYS> alter user maya default role all; User altered.



$ sqlplus conn maya/maya .. ... MAYA> select * from session_roles; ROLE ------------R1 R3 R2 SET ALL ROLES TO MAYA AS DEFAULT EXCEPT R2 SYS> alter user maya default role all except r2; User altered. SYS> select grantee, granted_role, default_role from dba_role_privs where grantee='MAYA'; GRANTEE

GRANTED_ROLE

DEF

------------------------------ ------------------------------ --MAYA

R1

YES

MAYA

R2

NO

MAYA

R3

YES

$ sqlplus maya/maya .. ... MAYA> select * from session_roles; ROLE ------------R1 R3 MAYA> set role all; Role set. MAYA> set role all; Role set. MAYA> select * from session_roles; ROLE ------------R1 R3 R2 If the role is password authenticated then you cannot grant it indirectly to the user. Manually you have to enable password authenticated roles by using SET ROLE statement. Here, role r2 as password authenticated. This cannot be a default role nor you can make it a default role. You can only set it explicitly by specifying the password. To enable or disable a role for a current session, you can use the SET ROLE statement.



ROLE FOR SYSTEM PRIVILEGE WITH ADMIN OPTION

SYS> revoke r1, r2, r3 from maya; Revoke succeeded. SYS> grant create any table to r1; Grant succeeded. SYS> grant create session to r1 with admin option; Grant succeeded. SYS> grant create session to PUBLIC; Grant succeeded.

GRANT A ROLE TO ANOTHER ROLE SYS> GRANT r1 TO r2; Grant succeeded. OWNER OF A ROLE Roles don't have owners, they are not schema objects. ASSIGNED PRIVILEGES OF THE ROLE SYS> select role, privilege from role_sys_privs where role=''; SYS> select role, privilege from role_sys_privs where role='R1'; DROP A ROLE SYS> drop role ; SYS> drop role r1;

ROLE FOR OBJECT PRIVILEGE To create a own role, you need CREATE ROLE privilege. SYS> grant create role, to sony; Grant succeeded. TABLE PRIVILEGE SYS> grant privilege ON owner. TO ; SYS> grant privilege ON TO ; SONY> create role testrole; Role created. SONY> grant select, insert, update, delete ON EMP to testrole; Grant succeeded NOTE: Cannot assign a privilege that includes the WITH GRANT OPTION to a role.



SONY> grant testrole to maya; Grant succeeded. SONY> revoke insert, update, delete on tab1 from testrole; Revoke succeeded. Maya can do SELECT operation on sony.tab1. ACTIVATE & DEACTIVATE ROLES Activate a role

SET ROLE ;

Activate a password protected role

SET ROLE IDENTIFIED BY ;

Activate all role

SET ROLE ALL;

Activate all role except one

SET ROLE ALL EXCEPT ;

Deactivate all roles

SET ROLE NONE;

SYSTEM PRIVILEGES FOR ROLES CREATE ROLE, DROP ROLE, GRANT ANY ROLE, ALTER ANY ROLE VIEWS FOR ROLES & PRIVILEGES DBA_USERS

Provides info about users.

DBA_ROLES

Shows all roles in the database

SESSION_PRIVS

Privileges currently enabled for current session

SESSION_ROLES

Lists roles currently enabled for the current session

DBA_SYS_PRIVS

Lists system privileges user is having

DBA_TAB_PRIVS

Displays object privileges user is holding

DBA_COL_PRIVS

Shows column level object grants.

DBA_ROLE_PRIVS

Displays which roles handling by user

ROLE_SYS_PRIVS

Shows system privileges granted to roles.

ROLE_TAB_PRIVS

Shows table privileges granted to roles.

ROLE_ROLE_PRIVS

Shows roles granted to roles

SAMPLE ROLE FOR ORACLE DEVELOPER SYS> CREATE ROLE oradev IDENTIFIED BY developer; GRANT CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE SYNONYM, CREATE TABLE, CREATE TRIGGER, CREATE TYPE, CREATE VIEW TO oradev; Role created.



TO FIND ASSIGNED ROLES TO THE USER SQL> select * from dba_role_privs where grantee='SONY'; TO FIND SYSTEM PRIVILEGE GRANTED TO ROLES SQL> select * from

dba_sys_privs where grantee='ORADEV'; -- # Role name

SQL> select * from

role_sys_privs where role='ORADEV';

FIND CURRENT SESSION ROLES AND PRIVILEGES SQL> select * from session_roles; SQL> select * from session_privs; TO TRACK OBJECT LEVEL PRIVILEGES SQL> select * from user_tab_privs; SQL> select * from dba_tab_privs where grantor='SCOTT'; SQL> select * from dba_col_privs where grantor='SCOTT'; USER MANAGEMET SQL STATEMENTS SQL> create user sham identified by shamdba; SQL> grant connect to sham; SQL> grant orcldev to sham;

# Role is assigned

SQL> alter user profile p1; SQL> alter user sham default tablespace users; SQL> alter user sham quota 1000m on users; SQL> alter user sham quota unlimited on tools; SQL> alter user sham temporary tablespace temp;

# Temp is temporary tablespace name

SQL> grant resource to sham;

# user will get unlimited tablespace privilege

SQL> grant DBA to sham;

# user will get all system privilege with admin option

SQL> grant connect, dba to rose identified by rose; SQL> grant connect, resource to scott identified by scott; SQL> create user sham identified by shamdba default tablespace users temporary tablespace temp quota 1000m on users quota unlimited on tbs2 profile p1; SQL> grant connect to sham;

# Resource role NOT assigned

SQL> grant orcldev to sham;

# orcldev is role

If you wish to grant system privileges without creating role, you can do it. But it is hard. SQL> grant create session to sham; SQL> grant create table, SQL> grant create view to sham; SQL> grant create procedure, create trigger to sham; ..


ROLES AND PRIVILEGES IN ORACLE.pdf

Recommend Documents