1. By Lecturer / Aisha Dawood 1

2.  Administering Users  Create and manage database user accounts.  Create and manage roles.  Grant and revoke privileges.  Control resource usage by users.  Oracle Database Security  Apply the principle of least privilege.  Manage default user accounts.  Implement standard password security features.  Audit database activity.  Register for security updates. 2

3.  Privileges allow a user to access database objects or execute stored programs that are owned by another user.  Privileges also enable a user to perform system-level operations, such as connecting to the database, creating a table, or altering the database.  Privileges are assigned to a user, to the special user PUBLIC, or to a role with the GRANT statement and can be rescinded with the REVOKE statement. 3

4.  An Oracle 10g database has three types of privileges:  Object privileges Permissions on schema objects such as tables, views, sequences, procedures, and packages. To use a schema object owned by another user, you need privileges on that object.  System privileges Permissions on database-level operations, such as connecting to the database, creating users, altering the database, or consuming unlimited amounts of tablespace.  Role privileges Object and system privileges that a user has by way of a role. Roles are tools for administering groups of privileges. 4

5.  Some privileges apply only to certain schema objects. For example, the INDEX privilege applies only to tables, and the SELECT privilege applies to tables, views, and sequences.  The following object privileges can be granted individually, grouped in a list, or with the keyword, ALL to implicitly grant all available object privileges for a particular schema object. 5

6.  Table object privileges Oracle 10g provides several object privileges for tables. These privileges give the table owner considerable flexibility in controlling how schema objects are used and by whom.  The following privileges are commonly granted:  SELECT The most commonly used privilege for tables. With this privilege, the table owner permits the grantee to query the specified table with a SELECT statement.  INSERT Permits the grantee to create new rows in the specified table with an INSERT statement.  UPDATE Permits the grantee to modify existing rows in the specified table with an UPDATE statement.  DELETE Permits the grantee to remove rows from the specified table with a DELETE statement.  The following are powerful administrative privileges on tables:  ALTER Permits the grantee to execute an ALTER TABLE statement on the specified table. This privilege can be used to add, modify, or rename columns in the table, to move the table to another tablespace, or even to rename the specified table.  DEBUG Permits the grantee to access, via a debugger, the PL/SQL code in any triggers on the specified table.  INDEX Permits the grantee to create new indexes on the table. These new indexes will be owned by a different user than the table, which is an unusual practice. In most cases, the indexes on a table are owned by the same user who owns the table itself.  REFERENCES Permits the grantee to create foreign key constraints that reference the specified table. 6

7.  View object privileges Oracle 10g offers a smaller set of object privileges for views than it does for tables.  SELECT The most commonly used privilege for views. With this privilege, the view owner permits the grantee to query the view.  INSERT Permits the grantee to execute an INSERT statement on the specified view to create new rows.  UPDATE Permits the grantee to modify existing rows in the specified view with an UPDATE statement.  DELETE Permits the grantee to execute a DELETE statement on the specified view to remove rows.  DEBUG Permits the grantee to access, via a debugger, the PL/SQL code in the body of any trigger on this view.  REFERENCES Permits the grantee create foreign key constraints on the specified view. 7

8.  You use the GRANT statement to confer object privileges on either a user or a role. The optional  For example, to give SELECT, INSERT, UPDATE, and DELETE privileges on the table CUSTOMERS to the role SALES_MANAGER, execute the following statement while connected as the owner of table CUSTOMERS: GRANT SELECT,INSERT,UPDATE,DELETE ON customers TO sales_manager; 8

9.  If you grant privileges to the special user PUBLIC, you make them available to all current and future database users.  For example, to give all database users the SELECT privilege on table CUSTOMERS, execute the following while connected as the owner of the table: GRANT SELECT ON customers TO public; 9

10.  When you extend a privilege to another user or role, you can also extend the ability for that grantee to turn around and grant the privilege to others. To extend this extra option, include the keywords WITH GRANT OPTION in the GRANT statement.  For example, to give the SELECT privilege on table SALES.CUSTOMERS to the user SALES_ADMIN together with the permission for SALES_ADMIN to grant the SELECT privilege to others, execute the following: GRANT SELECT ON sales.customers TO sales_admin WITH GRANT OPTION; NOTE: You can only include the WITH GRANT OPTION keywords when the grantee is a user or the special account PUBLIC. You cannot use WITH GRANT OPTION when the grantee is a role. 10

11.  If you grant an object privilege using the WITH GRANT OPTION keywords and later revoke that privilege, the revoke cascades, and the privileges created by the grantee are also revoked.  For example, Mary grants SELECT privileges on her table clients to Zachary with the WITH GRANT OPTION keywords. Zachary then creates a view based on the table mary.clients and grants the SELECT privilege on it to Rex. If Mary revokes the SELECT privilege from Zachary, the revoke cascades and removes the privilege from Rex. 11

12. 12 The revoking of object privilege cascades

13.  With object privileges, the database records both the grantor and the grantee. Therefore, a grantee can obtain a privilege from more than one grantor. When this multiple grant of the same privilege occurs, revoking one of these grants does not remove the privilege. To remove the privilege, all grants must be revoked.  Extending our previous example: Mary has granted SELECT on her table clients to Zachary using WITH GRANT OPTION. Zachary has then granted SELECT on mary.clients to Rex. Mary has also granted SELECT on her table clients to Charlie, who has in turn granted to Rex. Rex now has the SELECT privilege from more than one grantee. If Zachary leaves and his account is dropped, the privilege from Charlie remains and Rex can still select from mary.clients. 13

14. 14 The revoking of object privilege with multiple grant paths

15.  In general, system privileges permit the grantee to execute Data Definition Language (DDL)  statements—such as CREATE, ALTER, and DROP—or Data Manipulation Language (DML) statements system wide.  Database Oracle 10g gives you group of system privileges. Return to chapter 6 for full coverage. 15

16.  As with object privileges, you use the GRANT statement to confer system privileges on either a user or a role.  For example, to give the CREATE USER, ALTER USER, and DROP USER privileges to the role APPL_DBA, you execute the following statement: GRANT create user, alter user, drop user TO appl_dba;  The optional keywords WITH ADMIN OPTION are required to additionally allow the grantee to confer these privileges on other users and roles. 16

17.  As with object privileges, you can grant system privileges to the special user PUBLIC. Granting privileges to PUBLIC allows anyone with a database account to exercise this privilege.  For example, to give all current and future database users the FLASHBACK ANY TABLE privilege, execute the following: GRANT flashback any table TO public;  To give the INDEX ANY TABLE privilege to the role APPL_DBA together with the permission to allow anyone with the role APPL_DBA to grant this privilege to others, execute the following: GRANT index any table TO appl_dba WITH ADMIN OPTION; 17

18. WITH ADMIN OPTION vs WITH GRANT OPTION  If you grant a system privilege WITH ADMIN OPTION and later revoke that privilege, the privileges created by the grantee will not be revoked. Unlike object privileges, revocation of system privileges does not cascade.  For an example: Mary grants SELECT ANY TABLE privilege to new DBA Zachary with ADMIN OPTION. Zachary then grants this privilege to Rex. Later, Zachary gets promoted and leaves the department, so Mary revokes the SELECT ANY TABLE privilege from Zachary. Rex’s privilege remains unaffected. 18

19. 19 The revoking of system or role privileges

20.  Role privileges confer on the grantee a group of system, object, and other role privileges.  Users who have been granted a role inherit the privileges that have been granted to that role.  Roles can be password protected, so users may have a role granted to them, yet not be able to use that role in all database sessions.  A role is a tool for administering privileges. Privileges can be granted to a role, and then that role can be granted to other roles and users.  Users can thus inherit privileges via roles. Roles serve no other purpose than to administer privileges. 20

21.  To create a role, use the CREATE ROLE statement. You can optionally include an INDENTIFIED BY clause that requires users to authenticate themselves before enabling the role.  Roles requiring authentication are typically used inside an application, where a user’s activities are controlled by the application. To create the role APPL_DBA, execute the following: CREATE ROLE appl_dba;  To enable a role, execute a SET ROLE statement, like this: SET ROLE appl_dba IDENTIFIED BY seekwrit; 21

22.  As with object and system privileges, you use the GRANT statement to confer role privileges on either a user or another role.  Also, like system privileges, the optional keywords WITH ADMIN OPTION allow the grantee to confer these privileges on other users and roles.  For example, to give the OEM_MONITOR role to user charlie, execute the following: GRANT oem_monitor TO charlie;  As with the other privileges, you can grant role privileges to the special user PUBLIC. Granting privileges to PUBLIC allows anyone with a database account to exercise this privilege.  For example, to give all current and future database users use of the plustrace role, execute the following: GRANT plustrace TO public; 22

23.  To give the INDEX ANY TABLE privilege to the role APPL_DBA together with the permission to allow anyone with the role APPL_DBA to grant this privilege to others, execute the following: GRANT index any table TO appl_dba WITH ADMIN OPTION;  When it comes to granting a role WITH ADMIN OPTION, roles behave like system privileges, and subsequent revocations do not cascade. 23

24.  Roles can be enabled—or disabled for that matter—selectively in each database session.  If you have two concurrent sessions, the roles in effect for each session can be different.  Use the SET ROLE role_list statement to enable one or more roles. role_list is a comma-delimited list of roles to enable.  Include the following keywords:  The keyword ALL, which enables all the roles granted to the user.  You can optionally append a list of roles to exclude from the ALL list by specifying ALL EXCEPT exclusion_list.  If a role has a password associated with it, the keywords IDENTIFIED BY password must immediately follow the role name in the role_list. 24

25.  For example, to enable the password-protected role HR_ADMIN, together with the unprotected role EMPLOYEE, execute the following: SET ROLE hr_admin IDENTIFIED BY "my!seekrit", employee;  To enable all roles except HR_ADMIN, run this: SET ROLE ALL EXCEPT hr_admin;  You can enable as many roles as have been granted to you, up to the MAX_ENABLED_ROLES initialization parameter. 25

26.  Identifying Enabled Roles  The roles that are enabled in your session are listed in the data dictionary view SESSION_ROLES. To identify these enabled roles for your session, run the following: SELECT role FROM session_roles;  These roles include the roles that have been granted to you, the roles that have been granted to the special user PUBLIC, and the roles that you have inherited by way of other roles.  To identify the roles granted to either user or the special user PUBLIC, run the following: SELECT granted_role FROM user_role_privs WHERE username IN (USER, 'PUBLIC'); 26

27.  The role DBA includes the role SCHEDULER_ADMIN, which in turn has system privileges (such as CREATE ANY JOB).  A user who has been granted the DBA role inherits the SCHEDULER_ADMIN role indirectly.  To identify the roles that are both enabled in your session and granted directly to you or PUBLIC but not those roles that you inherited, run this: SELECT role FROM session_roles INTERSECT SELECT granted_role FROM user_role_privs WHERE username IN (USER, 'PUBLIC'); In your sessions, you can disable only these directly granted and public roles. 27

28.  Disabling Roles  Roles can be disabled in a database session either en masse or by exception.  Use the SET ROLE NONE statement to disable all roles. Use the SET ROLE ALL EXCEPT role_list statement to enable all roles except those in the comma-delimited role_list.  There is no way to selectively disable a single role. Also, you cannot disable roles that you inherit by way of another role without disabling the parent role. For example, you cannot disable the SCHEDULER_ADMIN role without disabling the DBA role. 28

29.  Setting Default Roles  Roles that are enabled by default when you log on are called default roles.  You do not need to specify a password for default roles and do not have to execute a SET ROLE statement to enable a default role.  Change the default roles for a user account with an ALTER USER DEFAULT ROLE role_list statement. The role_list can include the keywords ALL, NONE, and EXCEPT, in the same manner as with a SET ROLE statement. 29

30.  For example, to create the role EMPLOYEE, grant it to user scott, and configure all of scott’s roles except PLUSTRACE as default roles, run the following: CREATE ROLE employee; GRANT employee TO scott; ALTER USER scott DEFAULT ROLE ALL EXCEPT plustrace; 30

31.  Real world Scenario  Lucinda works in HR and needs to be able to modify an employee’s salary after they have a review and their raise is approved. The HR application ensures that the raise is approved and falls within corporate guidelines. Although Lucinda needs to be able to change employee salaries, she should be allowed to do so only from within the HR application, because it ensures that business rules are followed.  DBA Actions:  You wisely choose to use a password-protected role to satisfy these requirements. Update on the salary table is granted to the password- protected role salary_admin. Lucinda is then granted the salary_admin role, but she is not told the password for it. The HR application has the password encoded within it, so when Lucinda runs the HR application, unbeknownst to her, a SET ROLE salary_admin IDENTIFY BY password statement is executed, enabling the role and allowing her to change the salary.  If Lucinda tries to execute an UPDATE statement on the salary table from iSQLPlus, she will get an insufficient privileges error. 31