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 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
..
...
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 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
MOUNT AND DISMOUNT THE DATABASE
ALL SYSOPER PRIVILEGES +
OPEN AND CLOSE THE DATABASE
CREATE DATABASE COMMAND +
ALTER DATABASE ARCHIVELOG
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
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 <role_name>;

SYS> create role oradev;
SYS> create role <role_name> 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 <role_name> identified by <password>;

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 <role_name> to <user_name1, user_name2...>;

SYS> grant orcldev to sony, scott;
Grant succeeded.
ACTIVATE A ROLE
SCOTT> set role <role_name> identified by <password>;

SCOTT> set role orcldev identified by devdb;
TO DISABLING ALL ROLE
SCOTT> set role none;
GRANT A PRIVILEGE
SYS> grant <privilege_name> to <role_name>;

SYS> grant create any table to orcldev;
REVOKE A PRIVILEGE
SYS> grant <privilege_name> from <role_name>;

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 <user_name> default role <role_name>;
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='<role_name>';

SYS> select role, privilege from role_sys_privs where role='R1';
DROP A ROLE
SYS> drop role <role_name>;

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.<object_name> TO <role_name>;

SYS> grant privilege ON <object_name> TO <role_name>;
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 <ROLE_NAME>;

Activate a password protected role SET ROLE <ROLE_NAME> IDENTIFIED BY <ROLE_PASSWORD>;
Activate all role SET ROLE ALL;
Activate all role except one SET ROLE ALL EXCEPT <ROLE_NAME>;
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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Roles and Privileges in Oracle PDF

Uploaded by

Copyright:

Available Formats

ADMINSTRING ROLES AND PRIVILEGES IN ORACLE

ROLES AND PRIVILEGES

Roles are grouping of SYSTEM PRIVILEGES AND/OR OBJECT PRIVILEGES.

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

ROLE PRIVILEGE ADM

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

ROLE PRIVILEGE ADM

CREATE SESSION privilege is used to a user connect to the oracle database.

SYS> select * from ROLE_SYS_PRIVS where role = 'DBA';

ROLE PRIVILEGE ADM

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

SYS> grant create any index to rose;

SYS> grant create any table to rose WITH ADMIN OPTION;

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

GRANTEE PRIVILEGE ADM

ROSE> grant create any table to sony;

ROSE> grant create any index to sony;

Privilege is special right or permission.

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

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

SYSTEM PRIVILEGE can be displayed with following query.

SYS> SELECT NAME FROM SYSTEM_PRIVILEGE_MAP;

SYSTEM PRIVILEGES can be granted WITH ADMIN OPTION.

GRANTING & REVOKING SYSTEM LEVEL PRIVILEGES

SYS> GRANT create table to sham;

VIEWS FOR SYSTEM PRIVILEGES & ROLES

SESSION_PRIVS USER_SYS_PRIVS ALL_SYS_PRIVS ROLE_SYS_PRIVS

An application developer may have the following system privilege.

OBJECT PRIVILEGES can be granted WITH GRANT OPTION.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

GRANTING & REVOKING OBJECT LEVEL PRIVILEGES

SHAM> grant select on EMP to SCOTT;

SHAM> revoke update on EMP from SCOTT;

Public acts like a ROLE, sometimes acts like a USER.

SHAM> conn / as sysoper

PUBLIC> SHOW USER;

SYS> select user#, name, type# from user$ order by 1;

USER# NAME TYPE#

SHAM> grant select on EMP to PUBLIC;

SHAM> select * from USER_PRIVS_MADE;

GRANTEE TABLE_NAME GRANTOR PRIVILEGE GRA HIE

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

SHAM> revoke select on EMP from PUBLIC;

SHAM> select * from USER_TAB_PRIVS_MADE;

SYS> grant create session to PUBLIC;

SYS> select * from DBA_SYS_PRIVS where grantee in('PUBLIC');

GRANTEE PRIVILEGE ADM

TABLES VIEWS DIRECTORIES MATERIALIZED VIEWS

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

VIEWS FOR OBJECT LEVEL PRIVILEGES

DBA_TAB_PRIVS ALL_TAB_PRIVS USER_TAB_PRIVS

WITH GRANT AND WITH ADMIN OPTION

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;

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

GRANTEE PRIVILEGE ADM

A> grant create session to b WITH ADMIN OPTION;

B> grant create session to c WITH ADMIN OPTION;

C> revoke creation session from B;

C> revoke creation session from A;

A> grant create session to B WITH ADMIN OPTION;