Académique Documents
Professionnel Documents
Culture Documents
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.
8 rows selected.
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.
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?
Grant succeeded.
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
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.
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...
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
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.
CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE PROCEDURE, CREATE TRIGGER
PUBLIC MEANS
If a privilege has been granted to PUBLIC, all users in the database can use it.
The catalog table user$ contains both ROLES and USERS. If Column TYPE# value 1= USER and 0 = ROLE
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.
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
NOTE: Is there DROP TABLE PRIVILEGE in oracle? NO. DROP TABLE is NOT a PRIVILEGE.
SYSTEM PRIVILEGE can be granted WITH ADMIN OPTION. (SELECT, INSERT, UPDATE ...
OBJECT PRIVILEGE can be granted WITH GRANT OPTION. (CREATE SESSION, CREATE TABLE ...
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.
..
...
View created.
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
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.
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.
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.
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.
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
Quota: On TBS1 user has 1024 MB, on TBS2 user has 100 MB. -1 indicates Unlimited Quota on TBS3
AFTER REVOKE
Is everything fine now? No. When the user tries to create a new segment or extend an existing
one, you will get following error.
ROLES
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 indicates that this role is authorized by the database and no password is
required to enable the role. .
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.
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> GRANT
create table, create view, create synonym, create sequence, create trigger to orcldev;
Grant succeeded
ACTIVATE A ROLE
GRANT A PRIVILEGE
REVOKE A PRIVILEGE
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.
$ sqlplus maya/maya
..
...
ROLE
-------------
R1
R3
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.
OWNER OF A ROLE
DROP A ROLE
TABLE PRIVILEGE
CREATE ROLE, DROP ROLE, GRANT ANY ROLE, ALTER ANY ROLE
If you wish to grant system privileges without creating role, you can do it. But it is hard.