OCA/OCP Oracle Database 11g All-in-One Exam Guide 216 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 Chapter 6: Oracle Security 217 PART I • 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; grant create table to jon; OCA/OCP Oracle Database 11g All-in-One Exam Guide 218 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 Chapter 6: Oracle Security 219 PART I 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: Privilege Granted on SELECT Tables, views, sequences, synonyms INSERT Tables, views, synonyms UPDATE Tables, views, synonyms DELETE Tables, views, synonyms ALTER Tables, sequences EXECUTE Procedures, functions, packages, synonyms Figure 6-6 GRANT and REVOKE from SQL*Plus OCA/OCP Oracle Database 11g All-in-One Exam Guide 220 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 Chapter 6: Oracle Security 221 PART I 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; grant select on t1 to accounts; OCA/OCP Oracle Database 11g All-in-One Exam Guide 222 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. Chapter 6: Oracle Security 223 PART I 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 OCA/OCP Oracle Database 11g All-in-One Exam Guide 224 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 Chapter 6: Oracle Security 225 PART I • 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. . OCA/ OCP Oracle Database 11g All-in-One Exam Guide 216 3. Confirm that the users have been created with Database Control. From the database home page, the navigation path is the Server tab and. 9. As SALES, grant object privileges on the new table: grant all on t1 to webapp; grant select on t1 to accounts; OCA/ OCP Oracle Database 11g All-in-One Exam Guide 222 10. Connect to Database. to jon; OCA/ OCP Oracle Database 11g All-in-One Exam Guide 218 This gives SCOTT the ability to create tables in his own schema, and also to issue the GRANT command himself. In this example, he