Dm 0601wasserman PDF

© Copyright IBM Corporation 2006, 2012 TrademarksDB2 UDB security, Part 4: Understand how authorities andprivileges are implemented in DB2 UDB

Page 1 of 27

DB2 UDB security, Part 4: Understand how authoritiesand privileges are implemented in DB2 UDBTed J. Wasserman ([email protected])Database ConsultantIBM

20 September 2012(First published 01 May 2006)

A series of articles about IBM DB2 Universal Database for Linux, UNIX, and Windows (DB2UDB) V8.2 security features would not be complete without a discussion of the differentadministrative authority levels and privileges. This article is the fourth part of a series thatexamines the security features available in DB2 UDB V8.2.Part 1 looked at the user and group accounts that are required for DB2 UDB installation andoperation. Part 2 discussed how to enable and write your own security plug-ins, while Part 3looked at how security plug-ins could be customized to authenticate users. This article reviewsthe different administrative authority levels and privileges available in DB2 UDB and how theycan be granted to and revoked from user and group accounts.

View more content in this series

Introduction

In Part 1 of this series, you learned that certain user and group accounts are needed to install andoperate DB2 UDB V8.2. The important point to remember is that these accounts are defined in asecurity facility outside of DB2 UDB -- typically the operating system. User account management,including password policies, naming conventions, and group definitions, are all managed by thisexternal facility.

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ibm/trademarks/

mailto:[email protected]

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0508wasserman/

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0512chong/

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0512patil/

http://www.ibm.com/developerworks/views/db2/libraryview.jsp?search_by=db2+udb+security+series,


developerWorks® ibm.com/developerWorks/

DB2 UDB security, Part 4: Understand how authorities andprivileges are implemented in DB2 UDB

Page 2 of 27

Figure 1. Authentication versus authorization

DB2 UDB interacts with this external facility in order to validate a supplied user ID and passwordwhen a DB2 request is submitted. This interaction is referred to as authentication and is shown inthe bottom half of Figure 1. DB2 UDB relies on this external security facility to authenticate a userand will only grant access to DB2 UDB resources if authentication is successful.

Once authentication is successful, DB2 UDB must determine whether the user has the requiredpermissions to perform the intended operation. This process is known as authorization andis illustrated in the top half of Figure 1. DB2 UDB uses two internal mechanisms to determinewhether authorization is successful -- authority levels and privileges. We cover both of theseconcepts in more detail in the next sections.

Authority levels

DB2 UDB defines a hierarchy of authority levels to assign a set of pre-determined administrativerights to groups of user accounts. These administrative rights include the ability to take databasebackups, force users off the system, view table data, and more.

There are four instance authority levels (SYSADM, SYSCTRL, SYSMAINT, SYSMON) and twodatabase authority levels (DBAMD, LOAD). Authority levels that are defined at the instance-levelapply to all databases within the instance.

ibm.com/developerWorks/ developerWorks®


Page 3 of 27

Figure 2. Hierarchy of authority levels in DB2 UDB

Authority levels are arranged in the hierarchical format shown in Figure 2. At the top of thehierarchy is the SYSADM authority level, which is the highest level of authority a user can havein DB2 UDB. A user with SYSADM authority can perform all available DB2 operations. TheSYSCTRL and SYSMAINT authority levels provide a subset of SYSADM rights to manage thesystem but do not allow access to any data in the tables. The SYSMON authority provides theability to use the database system monitor. The DBADM authority allows a user to performadministrative tasks on a specific database in an instance and allows full access to the data andobjects in that database. The LOAD authority allows a user to run the LOAD utility, DB2 UDB'shigh-speed bulk data loader.

Table 1 summarizes each authority level and its intended use.

Table 1. Summary of each authority levelAuthority level Description and intended use

SYSADM • Highest level of administrative authority in DB2 UDB• Users with SYSADM authority can run utilities, issue database

and database manager commands, and access the data in anytable in any database within the database manager instance

• Provides the ability to control all database objects in theinstance, including databases, tables, views, indexes, packages,schemas, servers, aliases, data types, functions, procedures,triggers, table spaces, database partition groups, buffer pools,and event monitors

• Designed for DB2 UDB administrators requiring full access toutilities and data

SYSCTRL • Highest level of system control authority• Provides the ability to perform maintenance and utility

operations against the database manager instance and itsdatabases



Page 4 of 27

• Does not allow direct access to data in the databases• Has the implicit privilege to connect to a database and can

perform the functions of users with SYSMAINT and SYSMONauthority

• Designed for users administering a database manager instancecontaining sensitive data

SYSMAINT • Second highest level of system control authority• Provides the ability to perform maintenance and utility

operations against the database manager instance and itsdatabases

• Does not allow direct access to data in the databases• Has the implicit privilege to connect to a database, and can

perform the functions of users with SYSMON authority• Designed for users maintaining databases within a database

manager instance that contains sensitive data

SYSMON • Provides the ability to take snapshots of a database managerinstance or its databases

• Designed for users maintaining databases within a databasemanager instance that contains sensitive data and only requiresdiagnostic data for problem determination

• Does not have the ability to alter system resource usage

DBADM • The second highest level of administrative authority for a specificdatabase in an instance

• Allows the user to run certain utilities, issue databasecommands, and access the data in any table in the database

• Designed for administrators that require full access to databaseobjects and data, but not full maintenance rights

LOAD • Allows users to invoke the LOAD utility• Users also require INSERT and DELETE privileges on table

being loaded, depending on the mode of the LOAD operation• Designed for users who only require access to bulk load a new

set of data

Table 2 compares common administrative operations permitted for each authority level.



Page 5 of 27

Table 2. Comparison of operations permitted for each authority levelFunction SYSADM SYSCTRL SYSMAINT SYSMON DBADM LOAD

MIGRATEDATABASE

YES NO NO NO NO NO

GRANT/REVOKEDBADM

YES NO NO NO NO NO

UPDATE DBMCFG

YES NO NO NO NO NO

ESTABLISH/CHANGESYSCTRL/SYSMAINTAUTHORITY

YES NO NO NO NO NO

UPDATE DB/NODE/DCSDIRECTORIES

YES YES NO NO NO NO

FORCE USERSOFF DATABASE

YES YES NO NO NO NO

CREATE/DROPDATABASE

YES YES NO NO NO NO

CREATE/DROP/ALTER TABLESPACE

YES YES NO NO NO NO

RESTORE TONEW DATABASE

YES YES NO NO NO NO

UPDATE DB CFG YES YES YES NO NO NO

BACKUPDATABASE ORTABLE SPACE

YES YES YES NO NO NO

RESTORETO EXISTINGDATABASE


PERFORMROLLFORWARDRECOVERY


START/STOPDATABASEINSTANCE


RESTORE TABLESPACE


RUN TRACE YES YES YES NO NO NO

OBTAINMONITORSNAPSHOTS

YES YES YES YES NO NO

CREATE/ACTIVATE/DROPEVENT MONITOR

YES NO NO NO YES NO

QUERY TABLESPACE STATE

YES YES YES NO YES YES

PRUNE LOGHISTORY FILES

YES YES YES NO YES NO



Page 6 of 27

QUIESCEINSTANCES

YES YES NO NO NO NO

QUIESCEDATABASES

YES NO NO NO YES NO

QUIESCE TABLESPACE


REORG TABLE YES YES YES NO YES NO

RUN RUNSTATSUTILITY


LOAD TABLE YES NO NO NO YES YES

READ DATABASETABLE DATA

YES NO NO NO YES NO

Grant/Revoke instance-level authorities

Instance-level authorities are established by assigning user groups defined in the externalsecurity facility to the associated instance-level authority parameters (SYSADM_GROUP,SYSCTRL_GROUP, SYSMAINT_GROUP, SYSMON_GROUP). For example, if you wanted a useraccount called KATE to have SYSMAINT authority, you could put KATE in a group called MAINTand then update the instance parameter called SYSMAINT_GROUP to the value MAINT. Anyuser in the group MAINT would then have the SYSMAINT authority. To revoke the SYSMAINTauthority from KATE, you could simply remove her from the MAINT group or change the value ofthe SYSMAINT_GROUP parameter to a new group name that she is not a member of. In the lattercase, this would also revoke the SYSMAINT authority from other users in the MAINT group if theywere also not a member of the new group.

Instance level authority parameters can be changed from the command line or from the ControlCenter. For example, to change the value of the SYSMAINT_GROUP parameter to the valueMAINT using the command line, you can execute the following command:

Group names

Group names on all platforms must be 30 bytes or less in length.

update dbm cfg using SYSADM_GROUP MAINT

For the change to take effect, you must restart the DB2 UDB instance using the following twocommands:

db2stop

db2start

To ensure the change has taken effect, you can view the value of the parameter by issuing thefollowing command:

get dbm cfg



Page 7 of 27

The previous series of commands and results are illustrated in Listing 1. You can also update anyof the other instance-level authority parameters in a similar manner.

Listing 1. Update instance-level authority parameters using the command line

db2 => update dbm cfg using sysmaint_group maintDB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completedsuccessfully.

db2 => db2stop11/19/2005 21:19:03 0 0 SQL1064N DB2STOP processing was successful.SQL1064N DB2STOP processing was successful.

db2 => db2start11/19/2005 21:19:09 0 0 SQL1063N DB2START processing was successful.SQL1063N DB2START processing was successful.

db2 => get dbm cfg

Database Manager Configuration

Node type = Enterprise Server Edition with local and remote clients

.....

SYSADM group name (SYSADM_GROUP) = SYSCTRL group name (SYSCTRL_GROUP) = SYSMAINT group name (SYSMAINT_GROUP) = MAINT SYSMON group name (SYSMON_GROUP) =

.....

To change the value of the instance-level authority parameters using the control center, openControl Center, expand the All Systems folder, expand the target system, expand the Instancesfolder, right-click the target instance (in this example, DB2), and select the Configure Parametersitem (see Figure 3).



Page 8 of 27

Figure 3. Opening the configure parameters dialog in Control Center

Scroll through the list of parameters (Figure 4) and find the associated authority level parameters.Click the button beside the parameter value to change its value. In the example in Figure 4, wechanged the value of the SYSMAINT_GROUP parameter to the value MAINT.



Page 9 of 27

Figure 4. Changing the SYSMAINT_GROUP parameter in Control Center

You must stop and restart the instance for the parameter change to take effect. From the ControlCenter, right-click on the target instance again, and select the Stop item. If prompted to confirmstopping the instance, click the OK button. Right-click on the target instance again, and select theStart item. You can then go back and verify that the parameter change has taken effect.

In a default DB2 UDB installation on Windows, the values of these instance-level authorityparameters default to NULL. This means that any user account belonging to the localAdministrators group automatically inherits these authorities. For this reason, we highlyrecommend explicitly changing the value of these parameters to specific group names in orderprevent unintended/unauthorized access. On Linux and UNIX installations, this is not as large aconcern since a NULL value defaults to the primary group of the instance owner, which by defaultonly contains the user ID of the instance owner after an installation. However, it is still a goodpractice to set these parameters explicitly.

The database level authorities, such as DBADM, CONNECT, CREATETAB, and LOAD, aregranted and revoked in a similar way as database privileges. They are covered in the next section.

PrivilegesWhile instance authority levels are used as a mechanism to assign a pre-defined set ofadministrative rights to a group of user accounts, privileges are explicitly assigned to individualusers or groups to allow them to perform specific activities on database objects (for example, tocreate and drop an index). Privileges strictly define the tasks that a user can perform. For example,a user may have the privilege to read a table's data but not to update that data.



Page 10 of 27

Figure 5. Hierarchy of DB2 UDB authorities and privileges

Figure 5 shows the different levels of authorities and privileges available in DB2 UDB. This rangesfrom privileges on tables to privileges on schemas and stored procedures. The top of Figure 5shows the instance authority levels that were described in the previous section. Note how theSYSADM and DBADM authorities automatically receive all the authorities and privileges below thedotted line for a particular database.

Table 3 summarizes the types of database authorities that can be granted to and revoked fromusers or groups of users. Only users with SYSADM or DBADM authority can grant and revokethese authorities.

Table 3. Summary of the database level authoritiesDatabase authorities

CONNECT Allows the user to connect to the database

BINDADD Allows the user to create new packages in the database

CREATETAB Allows the user to create new tables in the database

CREATE_NOT_FENCED Allows the user to register a user-defined function (UDF) or storedprocedure that is defined as NOT FENCED

IMPLICIT SCHEMA Allows the user to create objects in a schema that does not alreadyexist (it creates the schema on-the-fly)*



Page 11 of 27

QUIESCE_CONNECT Allows the user to connect to the database while it is in a quiesced state

CREATE_EXTERNAL_ROUTINE Allows the user to register an external routine (a routine written in anexternal language, like C and Java)

*SYSIBM becomes the owner of the implicitly created schema, and the PUBLIC group is given theprivilege to create objects in this schema.

Table 4 summarizes the only available table space privilege (USE) that can be granted to andrevoked from users or groups of users. The USE privilege cannot be used with SYSCATSPACE oron any system temporary table spaces.

Table 4. Summary of table space privilegesTable space privileges

USE Allows the user to create tables in the specified table space

Table 5 summarizes the different types of schema privileges that can be granted to and revokedfrom users or groups of users.

Table 5. Summary of schema privilegesSchema privileges

CREATEIN Allows the user to create objects within the schema

ALTERIN Allows the user to alter objects within the schema

DROPIN Allows the user to drop objects from within the schema

Table 6 summarizes the different types of table/view privileges that can be granted to and revokedfrom users or groups of users.

Table 6. Summary of table and view privilegesTable/View privileges

CONTROL Gives the user all privileges on the table or view, as well as the ability togrant those privileges to others (except CONTROL)

ALTER Allows the user to add columns to a table, to add or change commentson a table and its columns, to add a primary key or unique constraint,and to create or drop a table check constraint

DELETE Allows the user to delete rows from a table or view

INDEX Allows the user to create an index on a table

INSERT Allows the user to insert data into a table or view

REFERENCES Allows the user to create and drop a foreign key, specifying the table asthe parent in a relationship

SELECT Allows the user to retrieve rows from a table or view, to create a view ona table, and to run the EXPORT utility

UPDATE Allows the user to change data in a table, a view, or one or morespecific columns in a table or view; the user may have this privilege onlyon specific columns



Page 12 of 27

Table 7 summarizes the only available index privilege (CONTROL) that can be granted to andrevoked from users or groups of users.

Table 7. Summary of index privilegesIndex privileges

CONTROL Allows the user to drop the index

Table 8 summarizes the different types of package privileges that can be granted to and revokedfrom users or groups of users. The section "Static and Dynamic SQL considerations" coverspackage concepts in more detail.

Table 8. Summary of package privilegesPackage privileges

CONTROL Allows the user to rebind, drop, or execute a package as well as theability to grant those privileges to others (except CONTROL)

BIND Allows the user to rebind an existing package

EXECUTE Allows the user to execute a package

Table 9 summarizes the only available routine privilege (EXECUTE) that can be granted to andrevoked from users or groups of users.

Table 9. Summary of routine privilegesRoutine privileges

EXECUTE Allows the user to invoke a routine, create a function that is sourcedfrom that routine (applies to functions only), and to reference the routinein any DDL statement, such as CREATE VIEW, CREATE TRIGGER, orwhen defining a constraint

Table 10 summarizes the different types of sequence privileges that can be granted to and revokedfrom users or groups of users.

Table 10. Summary of sequence privilegesSequence privileges

USAGE Allows the user to use NEXTVAL and PREVVAL expressions for thesequence

ALTER Allows the user to alter sequence properties using the ALTERSEQUENCE statement

Granting privilegesLike the instance-level authorities, privileges can be granted and revoked using command syntaxor the Control Center. In order to grant or revoke privileges, you must have a database connection.Figure 6 shows the syntax diagram for the GRANT statement for table and view privileges. TheGRANT statement syntax for other database objects is similar and is available in the DB2 UDBdocumentation.

http://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2.udb.doc/admin/t0005804.htm




Page 13 of 27

Figure 6. GRANT statement syntax diagram for tables and views

For example, to grant the INSERT privilege on the ACCOUNT table to user JEFF using theGRANT statement, you would issue the following statement:

GRANT INSERT ON TABLE account TO USER jeff

To grant the SELECT privilege on the CUSTOMER table to the group SALESREPS, you wouldissue the following statement:

GRANT SELECT ON TABLE customer TO GROUP salesreps

Care must be taken when granting authorities and privileges to a user or group, as DB2 UDB willlet you grant those privileges to a non-existent account. At some later time, an account might becreated with the same name and automatically receive all of the previously granted authorities andprivileges.

You can also grant privileges using the Control Center by expanding the All Databases folder,expanding the target database, expanding the folder containing the database object of interest,right-clicking on that object, and choosing the Privileges item. In Figure 7, we expanded theTables folder in the SAMPLE database, right-clicked on the EMPLOYEE table, and chose thePrivileges item.



Page 14 of 27

Figure 7. Table privileges dialog in Control Center

In the table privileges dialog window, you can select either the User or Group tab, depending onwhether you want to grant privileges to a user or group. If the user/group is not already in the list,click the Add User or Add Group button to add a user or group. You can specify which privilegesshould be granted to the user or group by clicking on the drop-down box for each privilege andselecting either Yes, No, or Grant. Selecting Yes means the privilege should be granted, selectingNo means the privilege should not be granted, and selecting Grant means the privilege should begranted as well as the privilege to grant other users/groups the privilege. Clicking the Grant Allbutton grants all the available privileges to the designated user or group. Clicking the Revoke Allbutton revokes all the available privileges from the designated user or group.

From Figure 7, you can see that a user called MARK has only been granted the INSERT privilegeon the EMPLOYEE table, meaning that MARK can only INSERT data into it, not read or updateit. This of course assumes that MARK is not a member of a group that has these privileges or hasSYSADM/DBADM authority.

Granting privileges to users versus groupsYou may have noticed from the examples above or the GRANT statement syntax diagram thatyou have the ability to specify whether you want to grant a privilege to a user or group, by usingthe TO USER or TO GROUP clauses respectively. If neither of these clauses is specified but thespecified name is defined in the operating system only as a group, then GROUP is assumed. Ifthe specified name is defined in the operating system only as user or if it is undefined, USER isassumed. If the specified name is defined in the operating system as both, an error is returned. As



Page 15 of 27

a best practice, we always recommend including either the TO USER or the TO GROUP clause inGRANT statements to avoid any ambiguity.

PUBLIC group

DB2 UDB internally uses a pseudo-group called PUBLIC, which privileges can be granted to andrevoked from. PUBLIC is not actually a group defined in the external security facility, but is rathera way to assign privileges to any user who successfully authenticates. You can grant privilegesto and revoke them from the PUBLIC group like any other group. For example, to revoke theIMPLICIT_SCHEMA authority from the PUBLIC group, you could issue the following statement:

REVOKE IMPLICIT_SCHEMA ON DATABASE FROM PUBLIC

It is important to understand the security implications of granting privileges to the PUBLIC group.Any user that supplies a valid user ID and password has the ability to perform any operation thePUBLIC group has been granted.

WITH GRANT OPTION

Many of the database object privileges also allow you to include the WITH GRANT OPTIONclause in the GRANT statement. This enables you to grant a privilege to a user/group while givingthe user or members of the group the right to grant the same privilege to other users/groups. Forexample, the following statement grants the ALTERIN, CREATEIN, and DROPIN privileges on theschema called ACCT to the group G1 as well as the ability for members of the group G1 to grantthose same privileges to other users or groups:

GRANT ALTERIN, CREATEIN, DROPIN ON SCHEMA ACCT TO GROUP G1 WITH GRANT OPTION

CONTROL privilege

The CONTROL privilege for an object cannot be granted to other users or groups using theWITH GRANT OPTION clause. It must be specifically granted to a user or group and canonly be done by someone with SYSADM or DBADM authority.

The WITH GRANT OPTION is only available for the GRANT statements of packages, routines,schemas, tables, views, and table spaces.

Revoking privileges

The REVOKE statement is used to revoke privileges that were previously granted. Figure 8 showsthe syntax diagram of the REVOKE statement for tables and views. Again, the REVOKE syntax forother database objects is similar and is available in the DB2 UDB documentation.




Page 16 of 27

Figure 8. REVOKE statement syntax diagram for tables and views

For example, to revoke the ALTER privilege on the STAFF table from user JEN, you could issuethe following statement:

REVOKE ALTER ON TABLE staff FROM USER jen

To revoke all privileges on the STAFF table from JEN, you could issue the following statement:

REVOKE ALL PRIVILEGES ON TABLE staff FROM USER jen

Privileges can also be revoked using the Control Center in the same way they were granted.Simply re-open the object privileges dialog window, as was previously shown in Figure 7. Torevoke a privilege, change the drop-down list for that privilege to NO, or click the Revoke Allbutton to revoke all the privileges associated with that object.

To revoke privileges on database objects, you must have DBADM authority, SYSADM authority,or CONTROL privilege on that object. Note that holding a privilege WITH GRANT OPTION is notsufficient to revoke that privilege. To revoke the CONTROL privilege from another user, you musthave SYSADM or DBADM authority.



Page 17 of 27

Revoking a privilege from a user or group revokes that privilege granted by any other account.However, revoking a privilege from a user or group does not revoke that same privilege from otheraccounts that were granted the privilege by that same user/group. For example, assume that userBEN grants SELECT WITH GRANT OPTION to user RICK, then RICK grants SELECT to usersRAVI and CHRIS. If BEN later revokes the SELECT privilege from RICK, RAVI and CHRIS stillretain the SELECT privilege.

Revoking specific privileges from a member of a groupYou may have a situation where you want to grant a privilege to a group and then revoke theprivilege from just one member of the group. However, you cannot revoke an explicit privilege thatwas never explicitly granted in the first place. You have two options in this case:

• You can remove the member from the group; or, create a new group with fewer members andgrant the privilege to the new group

• You can revoke the privilege from the group and then grant it to individual members of thegroup

Granting and revoking database authoritiesThe database level authorities, such as DBADM, LOAD, and CREATETAB are also granted toa user or a group using the GRANT statement. For example, the following statement grants theDBADM authority to the user SALLY:

GRANT DBADM ON DATABASE TO USER sally

The following statement grants the LOAD authority to the group MAINT:

GRANT LOAD ON DATABASE TO GROUP maint

Recall that users with the LOAD authority also require the INSERT privilege to load data into atable and the DELETE privilege if the LOAD operation is defined as REPLACE.

Revoking DBADM authorityTo revoke DBADM authority, you must have SYSADM authority.

To revoke database level authorities, use the REVOKE statement. For example, to revoke theLOAD authority from the group MAINT, you would issue the following statement:

REVOKE LOAD ON DATABASE FROM GROUP maint

Implicit privilegesIn some circumstances, the database manager implicitly grants certain privileges to a user whena user creates a database object, such as a table or a package, or when the DBADM authoritylevel is granted. It is important to understand which implicit privileges are granted and the securityimplications of these implicit privileges. Table 11 summarizes the cases where implicit privilegesare granted.



Page 18 of 27

Table 11. Summary of the implicit privileges granted for different actions

Action Implicit privileges granted to the user performing the action

Create a new database • GRANT of DBADM authority with BINDADD, CONNECT,CREATETAB, CREATE_EXTERNAL_ROUTINE,CREATE_NOT_FENCED_ROUTINE, IMPLICIT_SCHEMA,LOAD, and QUIESCE_CONNECT authorities to creator(SYSADM or SYSCTRL)

• GRANT of BINDADD, CREATETAB, CONNECT andIMPLICIT_SCHEMA to PUBLIC

• BIND and EXECUTE privilege on each successfully bound utilityto PUBLIC

• SELECT on system catalog tables and views to PUBLIC• USE privilege on USERSPACE1 table space to PUBLIC• EXECUTE WITH GRANT privilege to PUBLIC on all functions in

SYSFUN schema• EXECUTE privilege to PUBLIC on all procedures in SYSIBM

schema

Grant DBADM authority • GRANT of BINDADD, CONNECT, CREATETAB,CREATE_EXTERNAL_ROUTINE,CREATE_NOT_FENCED_ROUTINE, IMPLICIT_SCHEMA,LOAD and QUIESCE_CONNECT

Schema • When explicitly created, CREATEIN, ALTERIN, DROPIN isgranted to the user that created the schema

• When implicitly created, CREATEIN is additionally given toPUBLIC

Create object (table, index, package) • GRANT of CONTROL to object creator

Create a view • GRANT of the CONTROL privilege only if the user hasCONTROL privilege for all tables, views, and nicknamesreferenced in the view definition

For example, suppose you initially granted the DBADM authority to the user PAUL and at a latertime you decided to revoke that authority. To revoke the DBADM authority from PAUL, you coulduse the following statement:

REVOKE DBADM ON DATABASE FROM USER paul

After executing this command, PAUL would no longer have DBADM authority; however, he wouldstill have the GRANT, BINDADD, CONNECT, CREATETAB, CREATE_EXTERNAL_ROUTINE,CREATE_NOT_FENCED_ROUTINE, IMPLICIT_SCHEMA, LOAD and QUIESCE_CONNECTauthorities on the database that were implicitly granted when PAUL was originally granted theDBADM authority. These would need to be explicitly revoked from PAUL.

It is considered a good security practice to explicitly revoke many of the privileges that areimplicitly granted to PUBLIC after a new database is created. This helps lock down your systemand ensures only users who are supposed to access the database actually do.

Static and dynamic SQL considerations

When the syntax of an SQL statement is fully known at compile time, the statement is referred toas static SQL. This is in contrast to a dynamic SQL statement, whose syntax is not known untilrun-time.



Page 19 of 27

There are some differences in the way privileges are handled between static and dynamic SQL.One such difference is how group membership is handled. In general, group membership isonly considered for dynamic SQL and non-database object authorizations (such as instance-level commands and utilities). The one exception to this general case occurs when privileges aregranted to PUBLIC; these are considered when static SQL is processed.

Another difference is when authorization actually takes place. If a program is coded with staticSQL statements, packages (database objects that contain the optimized and executable form ofSQL statements) must be created in the database before the associated program can executethe SQL statements contained in the package. Authorization for static SQL takes place at compileor bind time. At run-time, a user only needs to have EXECUTE privileges on the package inorder to execute the statements in it. This does not imply that the user has direct access to theunderlying database objects. The only access to the underlying database objects is through thespecific statements in the package. For dynamic SQL statements, authorization takes place ona per statement basis. The user executing the statement must have the appropriate privileges toexecute that statement at run-time, either because they were explicitly granted them or possessthem through group membership.

For example, suppose the following static SQL statement is found in an embedded-SQLapplication:

EXEC SQL SELECT col INTO :hostvar FROM table123;

Suppose the application file containing this statement was pre-compiled, producing a bind filecalled sampleapp.bnd. If the developer BARBARA wanted to bind this file to the database (thuscreating a package), she would explicitly need to have the SELECT privilege on TABLE123 inorder for the BIND command to succeed. The one exception to this rule would be if the PUBLICgroup had been granted this privilege. BARBARA would also need the BINDADD authority, if thiswas a new package, or only the BIND privilege, if this was an existing package that she wanted tore-bind to the database (for example, because the database statistics were recently updated).

Packages may also include dynamic SQL, in which case the required privileges depend on thevalue that is specified for the DYNAMICRULES clause of the PRECOMPILE/BIND command whenthe package is precompiled or bound to the database. To use dynamic SQL in a package boundwith DYNAMICRULES RUN (the default), the user who runs a dynamic SQL application musthave the privileges necessary to issue each SQL request, as well as the EXECUTE privilege onthe package. The privileges may be granted to the user's ID, to any group of which the user is amember, or to PUBLIC.

If the application is bound with the DYNAMICRULES BIND option, DB2 UDB associates thepackage owner's user ID with the application packages. This allows any user who runs theapplication to inherit the privileges associated with the package owner's user ID.

For example, suppose the application file in the example above also contained dynamic SQL, asshown in Listing 2:



Page 20 of 27

Listing 2. Dynamic SQL in an embedded SQL applicationEXEC SQL BEGIN DECLARE SECTION; char hostVarStmt[50]; short hostVarDeptnum;EXEC SQL END DECLARE SECTION;

strcpy(hostVarStmt, "DELETE FROM org WHERE deptnum = ?");

EXEC SQL PREPARE Stmt1 FROM :hostVarStmt;

hostVarDeptnum = 15;EXEC SQL EXECUTE Stmt1 USING :hostVarDeptnum;

If BARBARA wanted to bind the same bind file to the database, she would need the BINDADDauthority if this was a new package or just the BIND privilege if the package already existed.Further, suppose BARBARA used the following BIND command to bind the file:

BIND sampleapp.bnd QUALIFIER u1 OWNER u2 DYNAMIC RULES RUN

In this case, all unqualified SQL statements (statements that did not qualify database objects witha schema) would use the schema U1. The user U2 would own the package because of the use ofthe OWNER clause. Since BARBARA specified the DYNAMIC RULES RUN clause, the privilegesof the user running the application (executing the package) are checked for dynamic SQL.

However, if BARBARA used the following BIND command to bind the file, the privileges of thepackage owner would be checked for dynamic SQL:

BIND sampleapp.bnd QUALIFIER u1 OWNER u2 DYNAMIC RULES BIND

In this case, the owner of the package is specified as U2. Thus at run-time, the privileges of theuser U2 are checked, rather than the user running the application.

Routine privilegesThe EXECUTE privilege applies to all types of routines, including functions, procedures, andmethods within the database. Once a user is granted the EXECUTE privilege for a routine, theuser can then invoke that routine, create a function that is sourced from that routine (appliesto functions only), and reference the routine in any DDL statement, such as CREATE VIEW orCREATE TRIGGER. Individual privileges for objects accessed inside the routine are not required.

How privileges/authorities are maintained in DB2 UDB

Instance level authoritiesInstance level authority levels (SYSADM, SYSCTRL, SYSMAINT, and SYSMON) and groupmembership are defined outside of DB2 UDB, and are therefore not reflected in systemcatalog tables.

DB2 UDB stores information about privileges in seven system catalog views:

• SYSCAT.DBAUTH - database privileges



Page 21 of 27

• SYSCAT.COLAUTH - table and view column privileges• SYSCAT.INDEXAUTH - index privileges• SYSCAT.PACKAGEAUTH - package privileges• SYSCAT.SCHEMAAUTH - schema privileges• SYSCAT.TABAUTH - table and view privileges• SYSCAT.TBSPACEAUTH - table space privileges

These views can be queried just like any other ones. For example, to find out what table privilegesa user EMMA has, you could issue the statement shown in Listing 3:

Listing 3. Querying the SYSCAT.TABAUTH view to find privilege information

SELECT substr(grantor,1,8) AS grantor, SUBSTR(grantee,1,8) AS grantee, granteetype AS gtype, SUBSTR (tabschema,1,8) AS schema, SUBSTR (tabname,1,8) AS tabname, controlauth AS ctl, alterauth AS alt, deleteauth AS del, indexauth AS idx, insertauth AS ins, selectauth AS sel, refauth AS ref, updateauth AS upd FROM syscat.tabauth WHERE grantee = 'EMMA'

GRANTOR GRANTEE GTYPE SCHEMA TABNAME CTL ALT DEL IDX INS SEL REF UPD------- -------- ----- -------- -------- --- --- --- --- --- --- --- ---INST1 EMMA U INST1 TABLE1 Y G G G G G G G

A grantee type (GTYPE) of 'U' means that the grantee (the account that holds the privilege) isa user account. A GTYPE value of 'G' means that the grantee is a group account. In the othercolumns, a value of 'Y' means the privilege is held, a value of 'N' means the privilege is not held,and a value of 'G' means the privilege is held and grantable to others. In Listing 3, you see that theuser EMMA has CONTROL privilege on the table TABLE1 as well as all the other available tableprivileges, including the ability to grant those privileges to other users.

Implicitly granted privileges

Privileges granted to users by the system will have SYSIBM as the grantor.

To find out all accounts with privileges, you can query each of the system catalog views andcombine the results together using the UNION operator, as shown in Listing 4:



Page 22 of 27

Listing 4. Determine all authorization names with privileges SELECT DISTINCT GRANTEE, GRANTEETYPE, 'DATABASE' FROM SYSCAT.DBAUTH UNION SELECT DISTINCT GRANTEE, GRANTEETYPE, 'TABLE ' FROM SYSCAT.TABAUTH UNION SELECT DISTINCT GRANTEE, GRANTEETYPE, 'PACKAGE ' FROM SYSCAT.PACKAGEAUTH UNION SELECT DISTINCT GRANTEE, GRANTEETYPE, 'INDEX ' FROM SYSCAT.INDEXAUTH UNION SELECT DISTINCT GRANTEE, GRANTEETYPE, 'COLUMN ' FROM SYSCAT.COLAUTH UNION SELECT DISTINCT GRANTEE, GRANTEETYPE, 'SCHEMA ' FROM SYSCAT.SCHEMAAUTH UNION SELECT DISTINCT GRANTEE, GRANTEETYPE, 'SERVER ' FROM SYSCAT.PASSTHRUAUTH ORDER BY GRANTEE, GRANTEETYPE, 3

You can also find out all the privileges a user or group has using the Control Center. To do this,open Control Center, expand the All Databases folder, expand the target database, expand theUsers and Group Objects folder, expand either the DB Users or DB Groups folder, and double-click the row for the user or group of interest. In Figure 9, the privileges dialog for the user MARKin the SAMPLE database is opened. By selecting the Database tab, you can see that the userMARK has the CONNECT and LOAD authorities. To revoke these authorities, you could uncheckthe box beside each authority.

Figure 9. Opening the change user (privileges) dialog in Control Center



Page 23 of 27

GET AUTHORIZATIONS commandDB2 UDB has a command called GET AUTHORIZATIONS that is a useful shortcut for reporting theauthorities of the current user. This command uses the values found in the database managerconfiguration file and the authorization system catalog view (SYSCAT.DBAUTH). Listing 5 showsthe results of issuing the command:

Listing 5. GET AUTHORIZATIONS command db2 => get authorizations

Administrative Authorizations for Current User

Direct SYSADM authority = NO Direct SYSCTRL authority = NO Direct SYSMAINT authority = NO Direct DBADM authority = NO Direct CREATETAB authority = NO Direct BINDADD authority = NO Direct CONNECT authority = NO Direct CREATE_NOT_FENC authority = NO Direct IMPLICIT_SCHEMA authority = NO Direct LOAD authority = NO Direct QUIESCE_CONNECT authority = NO Direct CREATE_EXTERNAL_ROUTINE authority = NO Direct SYSMON authority = NO

Indirect SYSADM authority = YES Indirect SYSCTRL authority = NO Indirect SYSMAINT authority = NO Indirect DBADM authority = NO Indirect CREATETAB authority = YES Indirect BINDADD authority = YES Indirect CONNECT authority = YES Indirect CREATE_NOT_FENC authority = NO Indirect IMPLICIT_SCHEMA authority = YES Indirect LOAD authority = NO Indirect QUIESCE_CONNECT authority = NO Indirect CREATE_EXTERNAL_ROUTINE authority = NO Indirect SYSMON authority = NO

Having a Direct authority means the authority was explicitly granted to the user. Having an Indirectauthority means the user belongs to a group that was granted that authority. A user might haveboth a direct and indirect authority if the user was explicitly granted that authority and belonged toa group that was granted that authority.

Deciding which privileges/authority levels are necessaryUsually, different users in your organization require different levels of database access. Forexample, a customer service representative would need a much more restrictive access level thana database administrator. This section presents a few scenarios and discusses the authorities andprivileges that are needed in each case.

Scenario 1

Tony, an analyst in the finance department, runs queries every morning to find out the profitabilityof the company's stores.



Page 24 of 27

In this case, Tony can be granted CONNECT privilege on the databases of interest, as well as theSELECT privilege on all the tables he requires access to.

Scenario 2

Janet, a database administrator, looks after all database maintenance activities for all databasesin the company. Her responsibilities include taking backups, restoring the database when required,storage management, and running traces. She should not be able to access any of the data in thedatabase.

In this case, Janet could be granted the SYSMAINT authority. SYSCTRL authority might also beconsidered if SYSMAINT is too restrictive.

Scenario 3

Jim, an application programmer, develops and tests the database manager application programs.He may also create tables of test data.

In this case, Jim requires BINDADD, BIND, CONNECT, and CREATETAB on one ormore databases, some specific schema privileges, and a list of privileges on some tables.CREATE_EXTERNAL_ROUTINE may also be required if he is developing routines in an externalprogramming language, like C or Java.

Scenario 4

Susan, a planner in the marketing department, needs to load the PRODUCT_SALES table withnew data she receives from the department stores every night in order to determine new buyingtrends.

In this case, Susan requires the CONNECT privilege on the database, the LOAD authority, as wellas the INSERT and SELECT privileges on the PRODUCT_SALES table.

Controlling access to database objects using schemas

A common question frequently asked by new DB2 UDB database administrators is how they canprovide an environment for their users to create and drop their own database objects while limitingthe access of these objects from other users. While giving each user his or her own physicaldatabase would solve the problem, it may not be the optimal solution. A better solution might be tocontrol database object access through the use of schemas.

Schemas are database objects used to logically group related database objects together. They arealso often used as a way to indicate object ownership. Schemas have privileges associated withthem, allowing the schema owner to control which users have the privilege to create, alter, anddrop objects in the schema. A schema owner is initially given all of these privileges on the schema,with the ability to grant them to others. A user with SYSADM or DBADM authority can change theprivileges held by users on any schema.



Page 25 of 27

By default, when a database is created, all users have the IMPLICIT_SCHEMA authority. Thisallows any user to create objects in any schema not already in existence. An implicitly createdschema allows any user to create other objects in the same schema. If the IMPLICIT_SCHEMAauthority is revoked from PUBLIC, schemas can be explicitly created using the CREATE SCHEMAstatement or implicitly created by users (such as those with DBADM authority) who have beenimplicitly granted the IMPLICIT_SCHEMA authority.

To give each user control of their own database objects, a database administrator could explicitlycreate a schema for each user. The administrator would then grant all the required privileges onthe schema only to each individual user. Other users would then be prevented from tamperingwith any objects created in the schema. To further lock down the system, the IMPLICIT_SCHEMAauthority could also be revoked from PUBLIC so that the only way a user could create a databaseobject would be through a designated schema which they had the appropriate privileges for. Thisapproach allows users to create whatever database objects they need and prevents them fromtampering or getting their database objects mixed up with those created by other users.

Summary

In this article, we have reviewed the different authority levels and privileges defined in DB2 UDBand how they can be assigned to users using command line syntax and the Control Center. Wealso discussed some of the finer details of privileges, including implicit privileges, the differencesin authorization between static and dynamic SQL, and how privilege information is stored in thesystem catalog tables. Finally, we covered how schemas can be used as an effective mechanismfor controlling access to database objects in multi-user environments. With this knowledge, youshould be able to define a privilege/authority strategy that minimizes the threat of accidental orintentional system misuse.



Page 26 of 27

Resources

Learn

• "Quick Beginnings for DB2 Servers Version 8.2": DB2 UDB documentation describing DB2UDB server installations.

• DB2 Online Information Center: The most recent DB2 online (and searchable)documentation.

• "DB2 UDB security, Part 1: Understand how user and group accounts interact with DB2UDB" (developerWorks, August 2005): This article describes the different user and groupaccounts needed to install and work with DB2 UDB for Linux, UNIX, and Windows, Version8.2 and introduces the DB2 UDB security model, including user authentication, user andgroup authorization, and super users.

• "DB2 UDB security, Part 2: Understand the DB2 Universal Database security plug-ins" (developerWorks, December 2005): Learn about the DB2 UDB security plug-ins, a newfeature introduced in Version 8.2. This article explains what the security plug-ins accomplishand teaches you how to enable and write your own security plug-ins.

• "DB2 UDB security, Part 3: Security plug-ins using the GSS-API security mechanisms(SPKM / LIPKEY)" (developerWorks, December 2005): Use the new GSS-API securitymechanisms to customize the DB2 UDB security plug-ins to achieve authentication based onpublic key technology.

• developerWorks Information Management zone: Find more resources for DB2 UDBdevelopers and administrators.

Get products and technologies

• IBM DB2 Universal Database Enterprise Server Edition V8.2 for Linux, UNIX, and Windows:Download a trial version from developerWorks.

• Build your next development project with IBM trial software, available for download directlyfrom developerWorks.

Discuss

• Participate in the discussion forum for this content.• developerWorks blogs: Get involved in the developerWorks community.

http://publib.boulder.ibm.com/infocenter/db2help/index.jsp







http://www.ibm.com/developerworks/db2/

http://www.ibm.com/developerworks/downloads/im/udb/index.html?S_TACT=105AGX11&S_CMP=art

http://www.ibm.com/developerworks/downloads/?S_TACT=105AGX11&S_CMP=art

http://www.ibm.com/developerworks/db2/community/

http://www.ibm.com/developerworks/blogs/



Page 27 of 27

About the author

Ted J. Wasserman

Ted J. Wasserman is a database consultant at the IBM Silicon Valley Laboratory inSan Jose, California. Ted works on the DB2 Business Partner Technical Enablementteam, where he specializes in helping IBM Business Partners migrate theirapplications and databases to DB2. Ted has a master's degree in computer science,as well as a bachelor's degree in computer science from Queen's University inKingston, Ontario, Canada.

© Copyright IBM Corporation 2006, 2012(www.ibm.com/legal/copytrade.shtml)Trademarks(www.ibm.com/developerworks/ibm/trademarks/)

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ibm/trademarks/

Dm 0601wasserman PDF

Documents

db2 udb resources

db2 udbpage

andoperate db2 udb v8

authority levelsdb2

trademarksdb2 udb security

27db2 udb security

db2 udbted

db2 request