ROLES AND PRIVILEGES IN ORACLE.pdf

ADMINSTRING ROLES AND PRIVILEGES IN ORACLE

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

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 DBAs) 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

..

...



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 users 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 To assign privileges or roles to a user, use GRANT command.

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

SYSTEM PRIVILEGES

SYSTEM PRIVILEGE is granted by DBAs. 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

ALL SYSOPER PRIVILEGES +

CREATE DATABASE COMMAND +

ALL SYSTEM PRIVLEGES WITH ADMIN OPTION

MOUNT AND DISMOUNT THE DATABASE

OPEN AND CLOSE THE DATABASE

ALTER DATABASE ARCHIVELOG

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

84 SCOTT 1

..

... 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');


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

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

Lets 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');


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

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');


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

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.

Lets 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

ROSE> grant select on SHAM.EMP to SCOTT WITH GRANT OPTION;

Grant succeeded.

ROSE> select * from user_tab_privs;


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

SCOTT SHAM EMP ROSE SELECT YES NO


SCOTT> grant select on SHAM.EMP to PUBLIC WITH GRANT OPTION;

Grant succeeded.

SCOTT> select * from user_tab_privs;


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

PUBLIC SHAM EMP SCOTT 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



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

PUBLIC SHAM EMP SCOTT 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.


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

Lets 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 wont have any

quota on any tablespace at all:

BEFORE REVOKE


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.


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.


Role created.


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.


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

..

...


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

..

...


ROLE

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

R1

R3

MAYA> set role all;

Role set.

MAYA> set role all;

Role set.


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

Documents

Transcript of ROLES AND PRIVILEGES IN ORACLE.pdf