Oracle Unleashed- P9

% sqlplus rhett Password: SQL> create table bonnie 2> ( 3> pony_column varchar2(15) 4> ) 5> tablespace users; Table created. SQL> grant select, insert, update on bonnie to scarlett; Grant succeeded. SQL> connect scarlett Enter password: SQL> select count(*) from rhett.bonnie; COUNT(*) ---------- 0 SQL> connect rhett Enter password: Connected. SQL> drop table bonnie; Table dropped. SQL> create table bonnie 2> ( 3> pony_column varchar2(15) 4> ) 5> tablespace users; Table created. SQL> connect scarlett Enter password: Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Connected. SQL> select count(*) from rhett.bonnie; Error at line 1: ORA-00942: table or view does not exist RHETT owns the table BONNIE, and he has granted SCARLETT access to the table. If BONNIE is dropped by RHETT and recreated with the same object name, SCARLETT no longer has access to the table. This is true until RHETT makes the grant again. If there were multiple grants, each grant must be made for each user on each database object. This can be quite cumbersome. The WITH GRANT OPTION Option In many environments, it is beneficial to have users other than the DBA perform grants. For example, the DBA might want to allow a project leader to grant rights on database objects to people working on his project. Thus, the DBA has to do the grants only once; then it falls to the project leader to make further grants as necessary. Oracle provides a mechanism for doing this: GRANT OPTION of the grant SQL command. With it, a user can issue grant commands just as though he were the actual owner of the database object. For example, % sqlplus aimee Password: Connected. SQL> grant select on order to jason with grant option; Grant succeeded. SQL> connect jason Enter password: Connected. SQL> grant select on aimee.order to lucinda; Grant succeeded. A database user who has received a grant with the ALL privilege does not receive GRANT OPTION automatically; it must be explicitly granted. As specified with object privileges above, GRANT OPTION remains in effect only until an object is dropped. SCARLETT owns a view of another database view called GEORGIA. This view is based on a table owned by another user, RHETT, and is called CHARLESTON. SCARLETT must have WITH GRANT OPTION on GEORGIA. If this is not done, grants of this view to other users will not work properly. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Resolving Object Synonyms A synonym is simply a designation for a database object that enables it to be referenced by another name. There are two types of these synonyms: private and public. A private synonym is a synonym created by the user that only he uses; no one other than the user who created the synonym can use it. A public synonym is accessible to all users in the database. Suppose, for example, that a user, TAL, has a table named HOCKEY for which two synonyms exist"ICE, a private synonym, and SPORT, a public synonym. This gives five distinct methods for accessing this particular table: ● As TAL, using the actual table name, HOCKEY. ● As TAL, using the private synonym name, ICE. ● As TAL, using the public synonym name, SPORT. ● As another user, using the database object owner and object name, TAL.HOCKEY. ● As another user, using the public synonym name, SPORT. This example assumes that the appropriate grants have been made on the HOCKEY table to permit access. In dealing with synonyms, it is important to understand the order in which the database resolves naming. This is important when you test programs for which there is a global table and a local table. Consider the following SQL statement: select * from emp; When it attempts to resolve this statement, the database first checks whether a database object "such as a table, view, or database link"exists and is owned by the current database user. If it finds a match, it stops. If a match does not exist, it checks for a private synonym that will direct it to a specific database object. If no private synonym exists, it checks for a public synonym that will point it toward an existing database object. If no resolution is found, if the database objects referenced by the synonyms do not exist, or if the user has no privileges on the object in question, an error condition occurs. System Security Whereas object privilege deals with what a user can do to database objects, system privilege deals with what actions a user can perform against the database itself. The actions include connecting to the database, creating database tables, and dropping an entire tablespace (with all the database objects in it). The functionality of Oracle7 makes the system privileges far more scaleable than in Oracle6. Under Oracle6, the Oracle RDBMS resembled UNIX in its overall security scheme. UNIX maintains that an account is either the root user or a regular user. Admittedly, UNIX has evolved to enable a greater deal of scalability by using things such as access control lists (ACLs) and root set userid (suid) programs. Oracle6 is set up so that all users are either the DBA or not the DBA. With the release of Oracle7, Oracle moves away from this methodology. It is possible now to grant specific privileges to non-DBA users, thereby enabling them to perform certain applications without giving them full DBA access. Defined System Privileges In Oracle6, three system privileges are available. Over 80 system privileges are available in Oracle7. The following is a partial list of the database system privileges. The information comes from the Oracle7 Server Administrator's Guide, an excellent reference that describes the capabilities of each privilege. ALTER DATABASE Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ALTER PROFILE ALTER RESOURCE COST ALTER ROLLBACK SEGMENT ALTER SESSION ALTER SYSTEM ALTER TABLESPACE ALTER USER AUDIT SYSTEM BECOME USER CREATE CLUSTER CREATE DATABASE LINK CREATE PROCEDURE CREATE PROFILE CREATE PUBLIC DATABASE LINK CREATE PUBLIC SYNONYM CREATE ROLE CREATE ROLLBACK SEGMENT CREATE SESSION CREATE SEQUENCE CREATE SNAPSHOT CREATE SYNONYM CREATE TABLE CREATE TABLESPACE CREATE TRIGGER Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CREATE USER CREATE VIEW DROP PROFILE DROP PUBLIC DATABASE LINK DROP PUBLIC SYNONYM DROP ROLLBACK SEGMENT DROP TABLESPACE DROP USER FORCE TRANSACTION MANAGE TABLESPACE READUP RESTRICTED SESSION UNLIMITED TABLESPACE Like object privileges, system privileges are given to users through the grant SQL command. The following code segment demonstrates how a system privilege grant is done: % sqlplus system Password: Connected. SQL> grant create session, alter session to anna; Grant succeeded. The revoke SQL command takes away system or object privileges that were given through the grant command. It is important to note that revoking a privilege does not destroy a database object. In the following example, the table remains even though the privilege to create new tables has been revoked: % sqlplus fred Password: Connected. SQL> select * from cat; TABLE_NAME TABLE_TYPE Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ------------------------------ ----------- SPORTS TABLE 1 rows selected. SQL> connect system Enter password: Connected. SQL> revoke create table from fred; Revoke succeeded. SQL> connect fred Enter password: Connected. SQL> select * from cat; TABLE_NAME TABLE_TYPE ------------------------------ ----------- SPORTS TABLE 1 rows selected. The WITH ADMIN OPTION Option WITH ADMIN OPTION is to database system privileges what WITH GRANT OPTION is to database object privileges. By making a grant WITH ADMIN OPTION, the DBA enables a user to grant the system privilege to another user. For example, % sqlplus system Password: SQL> grant create user to helpdesk with admin option; Grant succeeded. ANY Privileges The ANY privileges are a special class of privileges within the database system privileges. They are enhanced system privileges that grant the user the ability to perform specified actions without restrictions. If a user has these system privileges, he can override normal default security. Therefore, he has access to other database objects, regardless of whether an object-level grant is made. The following is a list of the ANY privileges. They are described in detail in the Oracle7 Server Administrator's Guide. ALTER ANY CLUSTER Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ALTER ANY INDEX ALTER ANY PROCEDURE ALTER ANY ROLE ALTER ANY SEQUENCE ALTER ANY SNAPSHOT ALTER ANY TABLE ALTER ANY TRIGGER BACKUP ANY TABLE COMMENT ANY TABLE CREATE ANY CLUSTER CREATE ANY INDEX CREATE ANY PROCEDURE CREATE ANY SEQUENCE CREATE ANY SNAPSHOT CREATE ANY SYNONYM CREATE ANY TABLE CREATE ANY TRIGGER CREATE ANY VIEW DELETE ANY TABLE DROP ANY CLUSTER DROP ANY INDEX DROP ANY PROCEDURE DROP ANY ROLE DROP ANY SEQUENCE Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. DROP ANY SNAPSHOT DROP ANY SYNONYM DROP ANY TABLE DROP ANY TRIGGER DROP ANY VIEW EXECUTE ANY PROCEDURE FORCE ANY TRANSACTION GRANT ANY PRIVILEGE GRANT ANY ROLE INSERT ANY TABLE LOCK ANY TABLE SELECT ANY SEQUENCE SELECT ANY TABLE UPDATE ANY TABLE The DBA should be careful when granting system privileges, especially the ANY class of privileges. Some of them are not meant for public use. They put too much power in the hands of users if they are not adequately managed. Although the privileges are more scaleable than under previous Oracle versions, the DBA should treat them as mini-DBA privileges when determining who should receive them. A final issue regarding protecting system privileges is what effect these privileges have within a secure database. In most databases, some tables contain information that should not be distributed to the general public, such as payroll information. A user with the some of the ANY privileges, such as SELECT ANY or UPDATE ANY, has access to the tables even without an explicit grant. Grants to PUBLIC It is possible to make grants on both system and object privileges to PUBLIC. This is a special Oracle account to which all other accounts have access. Any grant made to PUBLIC is accessible by any database user. For example, % sqlplus system Password: Connected. SQL> grant select on hr.emp_name to public; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Grant succeeded. The DBA can use the PUBLIC account to set up a common set of grants "such as the CREATE SESSION privilege, which permits connection to the database" and grant them to PUBLIC. In doing this, the DBA removes the need to make explicit grants to every user when a new account is added. The DBA can use PUBLIC to lock groups of users out of the database without having to restart the instance in RESTRICT mode. For example, he can grant CREATE SESSION to PUBLIC and make explicit CREATE SESSION grants to key users, such as IS personnel. In the event that activity needs to be done on the database, the following command can be executed from SQL*Plus or Oracle Server*Manager: revoke create session from public; This command effectively locks out everyone except the IS users after all the users have logged off the database. The grants can be reinstated as follows: grant create session to public; Object Security Model The DBA must consider other factors when setting up a security plan. Not only should the setup of the database users be considered, but also the ownership of the database objects. Although there is no right or wrong way to go about this, the following sections outline some of the concerns faced by the DBA when setting up object ownership models. Protected Object Ownership Schema One security model implemented by many sites is the protected schema "sometimes called the pure schema. Under this model, the DBA sets up an account that is not associated with any specific database user. This account is used as an ownership account for all the database objects"tables, views, and so on. Public synonyms are set up for each database object, and grants are made to each user for each database object. Therefore, a single user owns the objects, but the account can be restricted by not issuing passwords to any users except those who perform database object maintenance. There is nothing incredibly mystical about this setup. The object owner exists as just another account within the database. Depending on the environment, the DBA can configure the database to have only connection or resource privileges during maintenance windows and then revoke those privileges when completed. Thus, access to the object owner account can be given to other users "who might, for example, want to look at the contents of the CAT or USER_TABLES table" without enabling them to make changes to the database objects themselves. One important note here is that the DBA or person responsible for database object maintenance should maintain a build script for the object. Although this information can be obtained from the Oracle Data Dictionary, it is important to have this information accessible in emergency situations. Capacity Planning Requirements In dealing with database objects, one of the key elements for which the DBA is responsible is the capacity planning requirements of the database. Many sites hold to the philosophy that the creation and maintenance of the database objects responsibilities separate from overall database maintenance; most of these sites still agree that capacity planning is a responsibility of the DBA. Everything in the database is stored physically in database files. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Volumes have been written concerning the best ways to optimize the capacity planning of database objects within tablespaces. The main concern of capacity planning in this chapter is on security. Because users other than the DBA might be involved in creating database objects, he should stay abreast of modifications as they occur. For example, it takes only a typographical error in the STORAGE clause to inadvertently fill up a tablespace "1,000K and 10,000K are different by just one zero. When no further space is available to expand the tablespace, this can bring production databases to a screeching halt. By the same token, if the next extent sizes are set wrong forgetting the K in 512K makes it 512 bytes " a database object can quickly reach its MAXEXTENTS. When this happens, the only option is to rebuild the object with proper extent sizes. Depending on how much data is stored, this might be no small feat. The bottom line on capacity planning requirements from a database security standpoint is to be certain that accountability exists. Object creations should generally be limited to developers or analysts who have the technical knowledge to understand what object creation entails. It should not be necessary to hold anyone's hand. Likewise, they should not be given a blank check. Avoiding Tablespace Fragmentation Issues Given the prevalence of tools like Defrag by ARIS and TSReorg by Platinum Technology, tablespace fragmentation is an obvious problem for most DBAs. Tablespace fragmentation, illustrated in Figure 16.1, occurs when free space is available in a tablespace, but when the blocks of free space are not group in contiguous blocks. That is, they are not together. Although the amount of fragmentation in Oracle7 is much better than in Oracle6, it remains a persistent problem. Figure 16.1. Tablespace fragmentation. Many DBAs might wonder what tablespace fragmentation has to do with database security. The answer is simple: Steps that can be built into the security plan of the database that help minimize some of the main causes of database fragmentation. Suppose, for example, that a developer calls and complains that he cannot create a new table in tablespace XYZ. Whenever he tries to issue the CREATE TABLE command from SQL, he receives this error message: cannot allocate extent of size 99 in tablespace XYZ A quick check of the view DBA_FREE_SPACE shows the amount of free space available in the tablespace, so it is possible to calculate the total amount of free space capable of holding the table. The first question that the DBA should pose to the developer is, ÒHow often are you dropping tables and indexes?Ó This is the most common cause of tablespace fragmentation, especially for tablespaces to which developers have access. As a rule, developers perform CREATE TABLE/INDEX and DROP TABLE/INDEX operations on a regular basis, which inevitably leads to problems. It is a good idea to limit or eliminate access to the tablespaces on which production objects reside. You can do this by using tablespace quotas and by not giving anyone other than the protected schema access to the tablespaces. Generally, a special work tablespace called WORK or MISC is created. Developers can perform adds and drops on it. If this tablespace fragments, it can be defragmented at the DBA's discretion. If many people have access to the schema ownership account, it is often a good idea to revoke quotas on the tablespace from the schema until such a time as needed. This depends largely on the user community that is using the account. By limiting the amount of access to production tablespaces, the DBA can help reduce "although not eliminate" tablespace fragmentation. This helps eliminate the amount of crisis mode management that a DBA must undertake. Defining Database Roles Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... Privilege Roles Oracle6 has only three system privileges The privileges are q connect, which enables the user to connect to the database q resource, which enables the user to create objects in database tablespaces q dba, which gives the user full system rights on the database Oracle7 provides for backward compatibility by giving combination privileges that simulate the same functionality as their Oracle6 counterparts... not available as part of a role Oracle enables it specifically to deal with backward compatibility The Oracle7 EXP_FULL_DATABASE privileges that are assigned to a user by means of system privilege roles are SELECT ANY TABLE BACKUP ANY TABLE INSERT, UPDATE, and DELETE on SYS.INCEXP INSERT, UPDATE, and DELETE on SYS.INCVID INSERT, UPDATE, and DELETE on SYS.INCFIL The Oracle7 IMP_FULL_DATABASE privileges... future releases will not support them Although this seems unlikely given the amount of software that that relies on these privileges, you should be aware of it After all, Oracle undertook drastic changes when it moved from Oracle6 to Oracle7 Database Auditing This section on database auditing is the one that really causes the Mission: Impossible soundtrack to play louder Auditing gives the DBA the ability... capacity This problem is easily resolved As a DBA user, do connect internal from Oracle Server*Manager From Oracle Server*Manager, do truncate sys.aud$ This returns the database to its full operational capacity Operating System By directing the database to archive its information at the operating system level, the DBA enables Oracle to store its audit trail information in the same location as the audit... Password: Connected SQL> create role manager identified externally; Role created Each role to be used by the Oracle database instance must be defined as being identified externally in the database It must also be defined at the operating system The role always has the prefix ora_, following by the Oracle SID of the instance and the name of the role It can also have the suffix d (if it is a default role)... are BECOME USER The Oracle7 DBA privileges that are assigned to a user by means of system privilege roles are ALL PRIVILEGES WITH ADMIN OPTION EXP_FULL_DATABASE Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark IMP_FULL_DATABASE There have been rumors that these system roles have been provided only for backward compatibility with previous versions of Oracle and that future...In versions of Oracle prior to Oracle7 , explicit grants from the system and the object privilege level are the rule At first, this was not much of a hindrance because of the size of most databases Large databases were the exception;... packages q Snapshots Consult the Oracle7 Server Administrator's Guide for more information To deactivate object or privilege level auditing, bounce the database and set AUDIT_TRAIL to NONE, or specify the current audit options with the NOAUDIT command For example, % sqlplus system Password: Connected SQL> noaudit all; Statement processed Audit Trail Location The audit trails from Oracle' s AUDIT option can... roles of system privileges to accomplish this task The Oracle7 CONNECT privileges that are assigned to a user by means of system privilege roles are ALTER SESSION CREATE CLUSTER CREATE DATABASE LINK Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark CREATE SEQUENCE CREATE SESSION CREATE SYNONYM CREATE TABLE CREATE VIEW The Oracle7 RESOURCE privileges that are assigned to a user... designers should consider how they may want to use tablespaces to group database objects along logical boundaries One tablespace is always created when Oracle is installed This tablespace, called SYSTEM, houses all system tables and other system objects used by Oracle itself Although this tablespace can be used to house additional tables, it is preferable to create separate tablespaces for application-specific . objects in it). The functionality of Oracle7 makes the system privileges far more scaleable than in Oracle6 . Under Oracle6 , the Oracle RDBMS resembled UNIX in. set userid (suid) programs. Oracle6 is set up so that all users are either the DBA or not the DBA. With the release of Oracle7 , Oracle moves away from this