OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P27 pptx

The syntax for granting system privileges is GRANT privilege [, privilege...] TO username ; After creating a user account, a command such as this will grant the system privileges commonl

3 Confirm that the users have been created with Database Control From the database home page, the navigation path is the Server tab and the Users link

in the Security section They should look something like those shown in this illustration:

4 From SQL*Plus, attempt to connect as user SALES:

connect sales/sales

5 When prompted, select a new password (such as “oracle”) But it won’t get you anywhere, because user SALES does not have the CREATE SESSION privilege

6 Refresh the Database Control window, and note that the status of the SALES account is no longer EXPIRED but OPEN, because the password has been changed

Grant and Revoke Privileges

By default, no unauthorized user can do anything in an Oracle database A user cannot even connect without being granted a privilege And once this has been done, you still can’t do anything useful (or dangerous) without being given more privileges Privileges are assigned to user accounts with a GRANT command and withdrawn with

a REVOKE Additional syntax can give a user the ability to grant any privileges they have to other users By default only the database administrators (SYS and SYSTEM) have the right to grant any privileges The user that grants one or more privileges to

another user is referred to as the grantor while the recipient is referred to as the grantee.

Privileges come in two groups: system privileges that (generally speaking) let users perform actions that affect the data dictionary, and object privileges that let users perform actions that affect data

System Privileges

There are about two hundred system privileges Most apply to actions that affect the data dictionary, such as creating tables or users Others affect the database or the instance, such as creating tablespaces, adjusting instance parameter values, or establishing a session Some of the more commonly used privileges are

• CREATE SESSION This lets the user connect Without this, you cannot even

log on to the database

• RESTRICTED SESSION If the database is started with STARTUP RESTRICT,

or adjusted with ALTER SYSTEM ENABLE RESTRICTED SESSION, only users

with this privilege will be able to connect

• ALTER DATABASE Gives access to many commands necessary for modifying

physical structures

• ALTER SYSTEM Gives control over instance parameters and memory structures.

• CREATE TABLESPACE With the ALTER TABLESPACE and DROP

TABLESPACE privileges, these will let a user manage tablespaces

• CREATE TABLE Lets the grantee create tables in their own schema; includes

the ability to alter and drop them, to run SELECT and DML commands on

them, and to create, alter, or drop indexes on them

• GRANT ANY OBJECT PRIVILEGE Lets the grantee grant object permissions

on objects they don’t own to others—but not to themselves

• CREATE ANY TABLE The grantee can create tables that belong to other users.

• DROP ANY TABLE The grantee can drop tables belonging to any other users.

• INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY TABLE The grantee

can execute these DML commands against tables owned by all other users

• SELECT ANY TABLE The grantee can SELECT from any table in the database.

The syntax for granting system privileges is

GRANT privilege [, privilege ] TO username ;

After creating a user account, a command such as this will grant the system privileges

commonly assigned to users who will be involved in developing applications:

grant create session, alter session,

create table, create view, create synonym, create cluster,

create database link, create sequence,

create trigger, create type, create procedure, create operator

to username ;

These privileges will let you connect and configure your session, and then create

objects to store data and PL/SQL objects These objects can only exist in your own

schema; you will have no privileges against any other schema The object creation will

also be limited by the quota(s) you may (or may not) have been assigned on various

tablespaces

A variation in the syntax lets the grantee pass their privilege on to a third party For

example:

connect system/oracle;

grant create table to scott with admin option;

connect scott/tiger;

This gives SCOTT the ability to create tables in his own schema, and also to issue the GRANT command himself In this example, he lets user JON create tables too—but JON will only be able to create them in the JON schema Figure 6-5 shows the result

of the grant as depicted by Database Control; the same information could be garnered

by querying the view DBA_SYS_PRIVS

If a system privilege is revoked from you, any actions you performed using that privilege (such as creating tables) remain intact Also, if you had been granted the privilege with the ADMIN OPTION, any users to whom you passed on the privilege will retain it, even after it was revoked from you There is no record kept of the grantor

of a system privilege, so it is not possible for a REVOKE to cascade as illustrated in Figure 6-6

EXAM TIP Revocation of a system privilege will not cascade (unlike

revocation of an object privilege)

The ANY privileges give permissions against all relevant objects in the database Thus, grant select any table to scott;

will let SCOTT query every table in every schema in the database It is often

considered bad practice to grant the ANY privileges to any user other than the

system administration staff

Figure 6-5 System privileges granted to a user

TIP In fact, ANY is not as dangerous now as with earlier releases It no longer

includes tables in the SYS schema, so the data dictionary is still protected But

ANY should still be used with extreme caution, as it removes all protection

from user tables

Object Privileges

Object privileges provide the ability to perform SELECT, INSERT, UPDATE, and

DELETE commands against tables and related objects, and to execute PL/SQL objects

These privileges do not exist for objects in the users’ own schemas; if users have the

system privilege CREATE TABLE, they can perform SELECT and DML operations

against the tables they create with no further need for permissions

EXAM TIP The ANY privileges, that grant permissions against objects in

every user account in the database, are not object privileges—they are

system privileges

The object privileges apply to different types of object:

Figure 6-6

GRANT and

REVOKE from

SQL*Plus

The syntax is

GRANT privilege ON [schema.]object TO username [WITH GRANT OPTION] ;

For example,

grant select on store.customers to scott;

Variations include the use of ALL, which will apply all the permissions relevant to the type of object, and nominate particular columns of view or tables:

grant select on store.orders to scott;

grant update (order_status) on store.orders to scott;

grant all on store.regions to scott;

This code will let SCOTT query all columns of the ORDERS table in the STORE schema but only write to one nominated column, ORDER_STATUS Then SCOTT is given all the object privileges (SELECT and DML) on STORE’s REGIONS table Figure 6-7 shows the result of this, as viewed in Database Control

TIP Granting privileges at the column level is often said to be bad practice

because of the massive workload involved If it is necessary to restrict peoples’ access to certain columns, creating a view that shows only those columns will often be a better alternative

Figure 6-7 Object privilege management with Database Control

Using WITH GRANT OPTION (or with Database Control, selecting the Grant

Option check box shown in Figure 6-7) lets a user pass their object privilege on to

a third party Oracle retains a record of who granted object privileges to whom; this

allows a REVOKE of an object to cascade to all those in the chain Consider this

sequence of commands:

connect store/admin123;

grant select on customers to sales with grant option;

connect sales/sales;

grant select on store.customers to webapp with grant option;

conn webapp/oracle;

grant select on store.customers to scott;

connect store/admin123;

revoke select on customers from sales;

At the conclusion of these commands, neither SALES nor WEBAPP nor SCOTT has

the SELECT privilege against STORE.CUSTOMERS

EXAM TIP Revocation of an object privilege will cascade (unlike revocation of

a system privilege)

Exercise 6-2: Grant Direct Privileges In this exercise, you will grant some

privileges to the users created in Exercise 6-1 and prove that they work

1 Connect to your database as user SYSTEM with SQL*Plus

2 Grant CREATE SESSION to user SALES:

grant create session to sales;

3 Open another SQL*Plus session, and connect as SALES This time, the login

will succeed:

connect sales/oracle

4 As SALES, attempt to create a table:

create table t1 (c1 date);

This will fail with the message “ORA-01031: insufficient privileges.”

5 In the SYSTEM session, grant SALES the CREATE TABLE privilege:

grant create table to sales;

6 In the SALES session, try again:

create table t1 (c1 date);

This will fail with the message “ORA-01950: no privileges on tablespace

STOREDATA.”

7 In the SYSTEM session, give SALES a quota on the STOREDATA tablespace:

alter user sales quota 1m on storedata;

8 In the SALES session, try again This time, the creation will succeed

9 As SALES, grant object privileges on the new table:

grant all on t1 to webapp;

10 Connect to Database Control as user SYSTEM.

11 Confirm that the object privileges have been granted The navigation path

from the database home page is as follows: On the Schema tab click the Tables

link in the Database Objects section Enter SALES as the Schema and T1 as

the Table and click GO In the Actions drop-down box, select Object Privileges

As shown in the illustration, ACCOUNTS has only SELECT, but WEBAPP has everything else Note that the window also shows by whom the privileges were granted, and that none of them were granted WITH GRANT OPTION

12 With Database Control, confirm which privileges have granted to SALES The

navigation path from the database home page is as follows: On the Server tab click the Users link in the Security section Select the radio button for SALES, and click VIEW You will see that he has two system privileges (CREATE SESSION and CREATE TABLE) without the ADMIN OPTION, a 1MB quota on STOREDATA, and nothing else

13 Retrieve the same information shown in Steps 11 and 12 with SQL*Plus As

SYSTEM, run these queries:

select grantee,privilege,grantor,grantable from dba_tab_privs where owner='SALES' and table_name='T1';

select * from dba_sys_privs where grantee='SALES';

14 Revoke the privileges granted to WEBAPP and ACCOUNTS:

revoke all on sales.t1 from webapp;

revoke all on sales.t1 from accounts;

Confirm the revocations by rerunning the first query from Step 13.

Create and Manage Roles

Managing security with directly granted privileges works but has two problems First,

it can be a huge workload: an application with thousands of tables and users could

need millions of grants Second, if a privilege has been granted to a user, that user

has it in all circumstances: it is not possible to make a privilege active only in certain

circumstances Both these problems are solved by using roles A role is a bundle of

system and/or object privileges that can be granted and revoked as a unit, and having

been granted can be temporarily activated or deactivated within a session

Creating and Granting Roles

Roles are not schema objects: they aren’t owned by anyone and so cannot be prefixed

with a username However, they do share the same namespace as users: it is not possible

to create a role with the same name as an already-existing user, or a user with the same

name as an already-existing role

Create a role with the CREATE ROLE command:

CREATE ROLE rolename ;

Then grant privileges to the role with the usual syntax, including WITH ADMIN or

WITH GRANT OPTION if desired

For example, assume that the HR schema is being used as a repository for data to

be used by three groups of staff Managerial staff have full access, senior clerical staff

have limited access, and junior clerical staff have very restricted access First create a

role that might be suitable for the junior clerks; all they can do is answer questions

by running queries:

create role hr_junior;

grant create session to hr_junior;

grant select on hr.regions to hr_junior;

grant select on hr.locations to hr_junior;

grant select on hr.countries to hr_junior;

grant select on hr.departments to hr_junior;

grant select on hr.job_history to hr_junior;

grant select on hr.jobs to hr_junior;

grant select on hr.employees to hr_junior;

Anyone granted this role will be able to log on to the database and run SELECT

statements against the HR tables Then create a role for the senior clerks, who can also

write data to the EMPLOYEES and JOB_HISTORY tables:

create role hr_senior;

grant hr_junior to hr_senior with admin option;

grant insert, update, delete on hr.employees to hr_senior;

grant insert, update, delete on hr.job_history to hr_senior;

This role is first granted the HR_JUNIOR role (there is no problem granting one

role to another) with the syntax that will let the senior users assign the junior role to

others Then it is granted DML privileges on just two tables Then create the manager’s role, which can update all the other tables:

create role hr_manager;

grant hr_senior to hr_manager with admin option;

grant all on hr.regions to hr_manager;

grant all on hr.locations to hr_manager;

grant all on hr.countries to hr_manager;

grant all on hr.departments to hr_manager;

grant all on hr.job_history to hr_manager;

grant all on hr.jobs to hr_manager;

grant all on hr.employees to hr_manager;

This third role is given the HR_SENIOR role with the ability to pass it on, and then gets full control over the contents of all the tables But note that the only system privilege this role has is CREATE_SESSION, acquired through HR_SENIOR, which acquired it through HR_JUNIOR Not even this role can create or drop tables; that must be done by the HR user, or an administrator with CREATE ANY TABLE and DROP ANY TABLE

Note the syntax WITH ADMIN OPTION, which is the same as that for granting system privileges As with system privileges, revocation of a role will not cascade; there is no record kept of who has granted a role to whom

Finally, grant the roles to the relevant staff If SCOTT is a manager, SUE is a senior clerk, and JON and ROOP are junior clerks, the flow could be as in Figure 6-8

Predefined Roles

There are at least 50 predefined roles in an Oracle database (possibly many more, depending on what options have been installed) Roles that every DBA should be aware of are

• CONNECT This only exists for backward compatibility In previous releases it

had the system privileges necessary to create data storing objects, such as tables Now it has only the CREATE SESSION privilege

Figure 6-8

Granting roles

with SQL*Plus

• RESOURCE Also for backward compatibility, this role can create both data

objects (such as tables) and procedural objects (such PL/SQL procedures) It

also includes the UNLIMITED TABLESPACE privilege

• DBA Has most of the system privileges, and several object privileges and

roles Any user granted DBA can manage virtually all aspects of the database,

except for startup and shutdown

• SELECT_CATALOG_ROLE Has over 2000 object privileges against data

dictionary objects, but no system privileges or privileges against user data Useful

for junior administration staff who must monitor and report on the database

but not be able to see user data

• SCHEDULER_ADMIN Has the system privileges necessary for managing the

Scheduler job scheduling service

There is also a predefined role PUBLIC, which is always granted to every database

user account It follows that if a privilege is granted to PUBLIC, it will be available to

all users So following this command:

grant select on hr.regions to public;

all users will be able to query the HR.REGIONS table

TIP The PUBLIC role is treated differently from any other role It does not,

for example, appear in the view DBA_ROLES This is because the source code

for DBA_ROLES, which can be seen in the cdsec.sql script called by the

catalog.sql script, specifically excludes it

Enabling Roles

By default, if a user has been granted a role, then the role will be enabled This means

that the moment a session is established connecting to the user account, all the

privileges (and other roles) granted to the role will be active This behavior can

be modified by making the role nondefault Following the example given in the

preceding section, this query shows what roles have been granted to JON:

SQL> select * from dba_role_privs where grantee='JON';

GRANTEE GRANTED_ROLE ADM DEF

-JON HR_JUNIOR NO YES

JON has been granted HR_JUNIOR He does not have administration on the role

(so he cannot pass it on to anyone else), but it is a default role—he will have this role

whenever he connects This situation may well not be what you want For example,

JON has to be able to see the HR tables (it’s his job) but that doesn’t mean that you

want him to be able to dial in from home, at midnight, and hack into the tables with

SQL*Plus You want to arrange things such that he can only see the tables when he is

at a terminal in the Personnel office, running the HR application, in working hours