Академический Документы
Профессиональный Документы
Культура Документы
20 September 2012
(First published 01 May 2006)
A series of articles about IBM DB2 Universal Database for Linux, UNIX, and Windows (DB2
UDB) V8.2 security features would not be complete without a discussion of the different
administrative authority levels and privileges. This article is the fourth part of a series that
examines 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 and
operation. Part 2 discussed how to enable and write your own security plug-ins, while Part 3
looked at how security plug-ins could be customized to authenticate users. This article reviews
the different administrative authority levels and privileges available in DB2 UDB and how they
can 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 and
operate DB2 UDB V8.2. The important point to remember is that these accounts are defined in a
security facility outside of DB2 UDB -- typically the operating system. User account management,
including password policies, naming conventions, and group definitions, are all managed by this
external facility.
Trademarks
Page 1 of 27
developerWorks
ibm.com/developerWorks/
DB2 UDB interacts with this external facility in order to validate a supplied user ID and password
when a DB2 request is submitted. This interaction is referred to as authentication and is shown in
the bottom half of Figure 1. DB2 UDB relies on this external security facility to authenticate a user
and 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 required
permissions to perform the intended operation. This process is known as authorization and
is illustrated in the top half of Figure 1. DB2 UDB uses two internal mechanisms to determine
whether authorization is successful -- authority levels and privileges. We cover both of these
concepts in more detail in the next sections.
Authority levels
DB2 UDB defines a hierarchy of authority levels to assign a set of pre-determined administrative
rights to groups of user accounts. These administrative rights include the ability to take database
backups, force users off the system, view table data, and more.
There are four instance authority levels (SYSADM, SYSCTRL, SYSMAINT, SYSMON) and two
database authority levels (DBAMD, LOAD). Authority levels that are defined at the instance-level
apply to all databases within the instance.
DB2 UDB security, Part 4: Understand how authorities and
privileges are implemented in DB2 UDB
Page 2 of 27
ibm.com/developerWorks/
developerWorks
Authority levels are arranged in the hierarchical format shown in Figure 2. At the top of the
hierarchy is the SYSADM authority level, which is the highest level of authority a user can have
in DB2 UDB. A user with SYSADM authority can perform all available DB2 operations. The
SYSCTRL and SYSMAINT authority levels provide a subset of SYSADM rights to manage the
system but do not allow access to any data in the tables. The SYSMON authority provides the
ability to use the database system monitor. The DBADM authority allows a user to perform
administrative tasks on a specific database in an instance and allows full access to the data and
objects in that database. The LOAD authority allows a user to run the LOAD utility, DB2 UDB's
high-speed bulk data loader.
Table 1 summarizes each authority level and its intended use.
SYSADM
SYSCTRL
Page 3 of 27
developerWorks
ibm.com/developerWorks/
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 SYSMON
authority
Designed for users administering a database manager instance
containing sensitive data
SYSMAINT
SYSMON
DBADM
LOAD
Table 2 compares common administrative operations permitted for each authority level.
Page 4 of 27
ibm.com/developerWorks/
developerWorks
SYSADM
SYSCTRL
SYSMAINT
SYSMON
DBADM
LOAD
MIGRATE
DATABASE
YES
NO
NO
NO
NO
NO
GRANT/REVOKE
DBADM
YES
NO
NO
NO
NO
NO
UPDATE DBM
CFG
YES
NO
NO
NO
NO
NO
ESTABLISH/
CHANGE
SYSCTRL/
SYSMAINT
AUTHORITY
YES
NO
NO
NO
NO
NO
UPDATE DB/
NODE/DCS
DIRECTORIES
YES
YES
NO
NO
NO
NO
FORCE USERS
OFF DATABASE
YES
YES
NO
NO
NO
NO
CREATE/DROP
DATABASE
YES
YES
NO
NO
NO
NO
CREATE/DROP/
ALTER TABLE
SPACE
YES
YES
NO
NO
NO
NO
RESTORE TO
NEW DATABASE
YES
YES
NO
NO
NO
NO
UPDATE DB CFG
YES
YES
YES
NO
NO
NO
BACKUP
DATABASE OR
TABLE SPACE
YES
YES
YES
NO
NO
NO
RESTORE
TO EXISTING
DATABASE
YES
YES
YES
NO
NO
NO
PERFORM
ROLLFORWARD
RECOVERY
YES
YES
YES
NO
NO
NO
START/STOP
DATABASE
INSTANCE
YES
YES
YES
NO
NO
NO
RESTORE TABLE
SPACE
YES
YES
YES
NO
NO
NO
RUN TRACE
YES
YES
YES
NO
NO
NO
OBTAIN
MONITOR
SNAPSHOTS
YES
YES
YES
YES
NO
NO
CREATE/
YES
ACTIVATE/DROP
EVENT MONITOR
NO
NO
NO
YES
NO
QUERY TABLE
SPACE STATE
YES
YES
YES
NO
YES
YES
PRUNE LOG
HISTORY FILES
YES
YES
YES
NO
YES
NO
Page 5 of 27
developerWorks
ibm.com/developerWorks/
QUIESCE
INSTANCES
YES
YES
NO
NO
NO
NO
QUIESCE
DATABASES
YES
NO
NO
NO
YES
NO
QUIESCE TABLE
SPACE
YES
YES
YES
NO
YES
YES
REORG TABLE
YES
YES
YES
NO
YES
NO
RUN RUNSTATS
UTILITY
YES
YES
YES
NO
YES
YES
LOAD TABLE
YES
NO
NO
NO
YES
YES
READ DATABASE
TABLE DATA
YES
NO
NO
NO
YES
NO
Group names
Group names on all platforms must be 30 bytes or less in length.
For the change to take effect, you must restart the DB2 UDB instance using the following two
commands:
db2stop
db2start
To ensure the change has taken effect, you can view the value of the parameter by issuing the
following command:
get dbm cfg
DB2 UDB security, Part 4: Understand how authorities and
privileges are implemented in DB2 UDB
Page 6 of 27
ibm.com/developerWorks/
developerWorks
The previous series of commands and results are illustrated in Listing 1. You can also update any
of the other instance-level authority parameters in a similar manner.
(SYSADM_GROUP)
(SYSCTRL_GROUP)
(SYSMAINT_GROUP)
(SYSMON_GROUP)
=
=
= MAINT
=
.....
To change the value of the instance-level authority parameters using the control center, open
Control Center, expand the All Systems folder, expand the target system, expand the Instances
folder, right-click the target instance (in this example, DB2), and select the Configure Parameters
item (see Figure 3).
Page 7 of 27
developerWorks
ibm.com/developerWorks/
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, we
changed the value of the SYSMAINT_GROUP parameter to the value MAINT.
Page 8 of 27
ibm.com/developerWorks/
developerWorks
You must stop and restart the instance for the parameter change to take effect. From the Control
Center, right-click on the target instance again, and select the Stop item. If prompted to confirm
stopping the instance, click the OK button. Right-click on the target instance again, and select the
Start 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 authority
parameters default to NULL. This means that any user account belonging to the local
Administrators group automatically inherits these authorities. For this reason, we highly
recommend explicitly changing the value of these parameters to specific group names in order
prevent unintended/unauthorized access. On Linux and UNIX installations, this is not as large a
concern since a NULL value defaults to the primary group of the instance owner, which by default
only contains the user ID of the instance owner after an installation. However, it is still a good
practice to set these parameters explicitly.
The database level authorities, such as DBADM, CONNECT, CREATETAB, and LOAD, are
granted and revoked in a similar way as database privileges. They are covered in the next section.
Privileges
While instance authority levels are used as a mechanism to assign a pre-defined set of
administrative rights to a group of user accounts, privileges are explicitly assigned to individual
users or groups to allow them to perform specific activities on database objects (for example, to
create 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.
DB2 UDB security, Part 4: Understand how authorities and
privileges are implemented in DB2 UDB
Page 9 of 27
developerWorks
ibm.com/developerWorks/
Figure 5 shows the different levels of authorities and privileges available in DB2 UDB. This ranges
from privileges on tables to privileges on schemas and stored procedures. The top of Figure 5
shows the instance authority levels that were described in the previous section. Note how the
SYSADM and DBADM authorities automatically receive all the authorities and privileges below the
dotted line for a particular database.
Table 3 summarizes the types of database authorities that can be granted to and revoked from
users or groups of users. Only users with SYSADM or DBADM authority can grant and revoke
these authorities.
BINDADD
CREATETAB
CREATE_NOT_FENCED
IMPLICIT SCHEMA
Allows the user to create objects in a schema that does not already
exist (it creates the schema on-the-fly)*
Page 10 of 27
ibm.com/developerWorks/
developerWorks
QUIESCE_CONNECT
CREATE_EXTERNAL_ROUTINE
*SYSIBM becomes the owner of the implicitly created schema, and the PUBLIC group is given the
privilege to create objects in this schema.
Table 4 summarizes the only available table space privilege (USE) that can be granted to and
revoked from users or groups of users. The USE privilege cannot be used with SYSCATSPACE or
on any system temporary table spaces.
Table 5 summarizes the different types of schema privileges that can be granted to and revoked
from users or groups of users.
ALTERIN
DROPIN
Table 6 summarizes the different types of table/view privileges that can be granted to and revoked
from users or groups of users.
Gives the user all privileges on the table or view, as well as the ability to
grant those privileges to others (except CONTROL)
ALTER
DELETE
INDEX
INSERT
REFERENCES
Allows the user to create and drop a foreign key, specifying the table as
the parent in a relationship
SELECT
Allows the user to retrieve rows from a table or view, to create a view on
a table, and to run the EXPORT utility
UPDATE
Page 11 of 27
developerWorks
ibm.com/developerWorks/
Table 7 summarizes the only available index privilege (CONTROL) that can be granted to and
revoked from users or groups of users.
Table 8 summarizes the different types of package privileges that can be granted to and revoked
from users or groups of users. The section "Static and Dynamic SQL considerations" covers
package concepts in more detail.
BIND
EXECUTE
Table 9 summarizes the only available routine privilege (EXECUTE) that can be granted to and
revoked from users or groups of users.
Table 10 summarizes the different types of sequence privileges that can be granted to and revoked
from users or groups of users.
Allows the user to use NEXTVAL and PREVVAL expressions for the
sequence
ALTER
Granting privileges
Like the instance-level authorities, privileges can be granted and revoked using command syntax
or 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. The
GRANT statement syntax for other database objects is similar and is available in the DB2 UDB
documentation.
DB2 UDB security, Part 4: Understand how authorities and
privileges are implemented in DB2 UDB
Page 12 of 27
ibm.com/developerWorks/
developerWorks
For example, to grant the INSERT privilege on the ACCOUNT table to user JEFF using the
GRANT 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 would
issue 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 will
let you grant those privileges to a non-existent account. At some later time, an account might be
created with the same name and automatically receive all of the previously granted authorities and
privileges.
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 the
Tables folder in the SAMPLE database, right-clicked on the EMPLOYEE table, and chose the
Privileges item.
DB2 UDB security, Part 4: Understand how authorities and
privileges are implemented in DB2 UDB
Page 13 of 27
developerWorks
ibm.com/developerWorks/
In the table privileges dialog window, you can select either the User or Group tab, depending on
whether 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 privileges
should be granted to the user or group by clicking on the drop-down box for each privilege and
selecting either Yes, No, or Grant. Selecting Yes means the privilege should be granted, selecting
No means the privilege should not be granted, and selecting Grant means the privilege should be
granted as well as the privilege to grant other users/groups the privilege. Clicking the Grant All
button grants all the available privileges to the designated user or group. Clicking the Revoke All
button 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 privilege
on the EMPLOYEE table, meaning that MARK can only INSERT data into it, not read or update
it. This of course assumes that MARK is not a member of a group that has these privileges or has
SYSADM/DBADM authority.
Page 14 of 27
ibm.com/developerWorks/
developerWorks
a best practice, we always recommend including either the TO USER or the TO GROUP clause in
GRANT statements to avoid any ambiguity.
PUBLIC group
DB2 UDB internally uses a pseudo-group called PUBLIC, which privileges can be granted to and
revoked from. PUBLIC is not actually a group defined in the external security facility, but is rather
a way to assign privileges to any user who successfully authenticates. You can grant privileges
to and revoke them from the PUBLIC group like any other group. For example, to revoke the
IMPLICIT_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 the
PUBLIC group has been granted.
CONTROL privilege
The CONTROL privilege for an object cannot be granted to other users or groups using the
WITH GRANT OPTION clause. It must be specifically granted to a user or group and can
only 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 shows
the syntax diagram of the REVOKE statement for tables and views. Again, the REVOKE syntax for
other database objects is similar and is available in the DB2 UDB documentation.
Page 15 of 27
developerWorks
ibm.com/developerWorks/
For example, to revoke the ALTER privilege on the STAFF table from user JEN, you could issue
the 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. To
revoke a privilege, change the drop-down list for that privilege to NO, or click the Revoke All
button 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 not
sufficient to revoke that privilege. To revoke the CONTROL privilege from another user, you must
have SYSADM or DBADM authority.
Page 16 of 27
ibm.com/developerWorks/
developerWorks
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 other
accounts that were granted the privilege by that same user/group. For example, assume that user
BEN grants SELECT WITH GRANT OPTION to user RICK, then RICK grants SELECT to users
RAVI and CHRIS. If BEN later revokes the SELECT privilege from RICK, RAVI and CHRIS still
retain the SELECT privilege.
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 a
table and the DELETE privilege if the LOAD operation is defined as REPLACE.
To revoke database level authorities, use the REVOKE statement. For example, to revoke the
LOAD authority from the group MAINT, you would issue the following statement:
REVOKE LOAD ON DATABASE FROM GROUP maint
Implicit privileges
In some circumstances, the database manager implicitly grants certain privileges to a user when
a user creates a database object, such as a table or a package, or when the DBADM authority
level is granted. It is important to understand which implicit privileges are granted and the security
implications of these implicit privileges. Table 11 summarizes the cases where implicit privileges
are granted.
DB2 UDB security, Part 4: Understand how authorities and
privileges are implemented in DB2 UDB
Page 17 of 27
developerWorks
ibm.com/developerWorks/
Table 11. Summary of the implicit privileges granted for different actions
Action
Schema
Create a view
For example, suppose you initially granted the DBADM authority to the user PAUL and at a later
time you decided to revoke that authority. To revoke the DBADM authority from PAUL, you could
use the following statement:
REVOKE DBADM ON DATABASE FROM USER paul
After executing this command, PAUL would no longer have DBADM authority; however, he would
still have the GRANT, BINDADD, CONNECT, CREATETAB, CREATE_EXTERNAL_ROUTINE,
CREATE_NOT_FENCED_ROUTINE, IMPLICIT_SCHEMA, LOAD and QUIESCE_CONNECT
authorities on the database that were implicitly granted when PAUL was originally granted the
DBADM 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 are
implicitly granted to PUBLIC after a new database is created. This helps lock down your system
and ensures only users who are supposed to access the database actually do.
Page 18 of 27
ibm.com/developerWorks/
developerWorks
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 is
only considered for dynamic SQL and non-database object authorizations (such as instancelevel commands and utilities). The one exception to this general case occurs when privileges are
granted to PUBLIC; these are considered when static SQL is processed.
Another difference is when authorization actually takes place. If a program is coded with static
SQL statements, packages (database objects that contain the optimized and executable form of
SQL statements) must be created in the database before the associated program can execute
the SQL statements contained in the package. Authorization for static SQL takes place at compile
or bind time. At run-time, a user only needs to have EXECUTE privileges on the package in
order to execute the statements in it. This does not imply that the user has direct access to the
underlying database objects. The only access to the underlying database objects is through the
specific statements in the package. For dynamic SQL statements, authorization takes place on
a per statement basis. The user executing the statement must have the appropriate privileges to
execute that statement at run-time, either because they were explicitly granted them or possess
them through group membership.
For example, suppose the following static SQL statement is found in an embedded-SQL
application:
EXEC SQL SELECT col INTO :hostvar FROM table123;
Suppose the application file containing this statement was pre-compiled, producing a bind file
called sampleapp.bnd. If the developer BARBARA wanted to bind this file to the database (thus
creating a package), she would explicitly need to have the SELECT privilege on TABLE123 in
order for the BIND command to succeed. The one exception to this rule would be if the PUBLIC
group had been granted this privilege. BARBARA would also need the BINDADD authority, if this
was a new package, or only the BIND privilege, if this was an existing package that she wanted to
re-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 the
value that is specified for the DYNAMICRULES clause of the PRECOMPILE/BIND command when
the package is precompiled or bound to the database. To use dynamic SQL in a package bound
with DYNAMICRULES RUN (the default), the user who runs a dynamic SQL application must
have the privileges necessary to issue each SQL request, as well as the EXECUTE privilege on
the package. The privileges may be granted to the user's ID, to any group of which the user is a
member, or to PUBLIC.
If the application is bound with the DYNAMICRULES BIND option, DB2 UDB associates the
package owner's user ID with the application packages. This allows any user who runs the
application 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, as
shown in Listing 2:
Page 19 of 27
developerWorks
ibm.com/developerWorks/
If BARBARA wanted to bind the same bind file to the database, she would need the BINDADD
authority 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 with
a schema) would use the schema U1. The user U2 would own the package because of the use of
the OWNER clause. Since BARBARA specified the DYNAMIC RULES RUN clause, the privileges
of 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 the
package 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 the
user U2 are checked, rather than the user running the application.
Routine privileges
The EXECUTE privilege applies to all types of routines, including functions, procedures, and
methods within the database. Once a user is granted the EXECUTE privilege for a routine, the
user can then invoke that routine, create a function that is sourced from that routine (applies
to functions only), and reference the routine in any DDL statement, such as CREATE VIEW or
CREATE TRIGGER. Individual privileges for objects accessed inside the routine are not required.
DB2 UDB stores information about privileges in seven system catalog views:
SYSCAT.DBAUTH - database privileges
DB2 UDB security, Part 4: Understand how authorities and
privileges are implemented in DB2 UDB
Page 20 of 27
ibm.com/developerWorks/
developerWorks
These views can be queried just like any other ones. For example, to find out what table privileges
a user EMMA has, you could issue the statement shown in Listing 3:
A grantee type (GTYPE) of 'U' means that the grantee (the account that holds the privilege) is
a user account. A GTYPE value of 'G' means that the grantee is a group account. In the other
columns, 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 the
user EMMA has CONTROL privilege on the table TABLE1 as well as all the other available table
privileges, including the ability to grant those privileges to other users.
To find out all accounts with privileges, you can query each of the system catalog views and
combine the results together using the UNION operator, as shown in Listing 4:
Page 21 of 27
developerWorks
ibm.com/developerWorks/
'COLUMN
'SCHEMA
'SERVER
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 the
Users and Group Objects folder, expand either the DB Users or DB Groups folder, and doubleclick the row for the user or group of interest. In Figure 9, the privileges dialog for the user MARK
in the SAMPLE database is opened. By selecting the Database tab, you can see that the user
MARK has the CONNECT and LOAD authorities. To revoke these authorities, you could uncheck
the box beside each authority.
Page 22 of 27
ibm.com/developerWorks/
developerWorks
SYSADM authority
SYSCTRL authority
SYSMAINT authority
DBADM authority
CREATETAB authority
BINDADD authority
CONNECT authority
CREATE_NOT_FENC authority
IMPLICIT_SCHEMA authority
LOAD authority
QUIESCE_CONNECT authority
CREATE_EXTERNAL_ROUTINE authority
SYSMON authority
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
Indirect
SYSADM authority
SYSCTRL authority
SYSMAINT authority
DBADM authority
CREATETAB authority
BINDADD authority
CONNECT authority
CREATE_NOT_FENC authority
IMPLICIT_SCHEMA authority
LOAD authority
QUIESCE_CONNECT authority
CREATE_EXTERNAL_ROUTINE authority
SYSMON authority
=
=
=
=
=
=
=
=
=
=
=
=
=
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
=
=
=
=
=
=
=
=
=
=
=
=
=
YES
NO
NO
NO
YES
YES
YES
NO
YES
NO
NO
NO
NO
Having a Direct authority means the authority was explicitly granted to the user. Having an Indirect
authority means the user belongs to a group that was granted that authority. A user might have
both a direct and indirect authority if the user was explicitly granted that authority and belonged to
a group that was granted that authority.
Page 23 of 27
developerWorks
ibm.com/developerWorks/
In this case, Tony can be granted CONNECT privilege on the databases of interest, as well as the
SELECT privilege on all the tables he requires access to.
Scenario 2
Janet, a database administrator, looks after all database maintenance activities for all databases
in 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 the
database.
In this case, Janet could be granted the SYSMAINT authority. SYSCTRL authority might also be
considered 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 or
more 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 external
programming language, like C or Java.
Scenario 4
Susan, a planner in the marketing department, needs to load the PRODUCT_SALES table with
new data she receives from the department stores every night in order to determine new buying
trends.
In this case, Susan requires the CONNECT privilege on the database, the LOAD authority, as well
as the INSERT and SELECT privileges on the PRODUCT_SALES table.
Page 24 of 27
ibm.com/developerWorks/
developerWorks
By default, when a database is created, all users have the IMPLICIT_SCHEMA authority. This
allows any user to create objects in any schema not already in existence. An implicitly created
schema allows any user to create other objects in the same schema. If the IMPLICIT_SCHEMA
authority is revoked from PUBLIC, schemas can be explicitly created using the CREATE SCHEMA
statement or implicitly created by users (such as those with DBADM authority) who have been
implicitly granted the IMPLICIT_SCHEMA authority.
To give each user control of their own database objects, a database administrator could explicitly
create a schema for each user. The administrator would then grant all the required privileges on
the schema only to each individual user. Other users would then be prevented from tampering
with any objects created in the schema. To further lock down the system, the IMPLICIT_SCHEMA
authority could also be revoked from PUBLIC so that the only way a user could create a database
object would be through a designated schema which they had the appropriate privileges for. This
approach allows users to create whatever database objects they need and prevents them from
tampering 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 UDB
and how they can be assigned to users using command line syntax and the Control Center. We
also discussed some of the finer details of privileges, including implicit privileges, the differences
in authorization between static and dynamic SQL, and how privilege information is stored in the
system catalog tables. Finally, we covered how schemas can be used as an effective mechanism
for controlling access to database objects in multi-user environments. With this knowledge, you
should be able to define a privilege/authority strategy that minimizes the threat of accidental or
intentional system misuse.
Page 25 of 27
developerWorks
ibm.com/developerWorks/
Resources
Learn
"Quick Beginnings for DB2 Servers Version 8.2": DB2 UDB documentation describing DB2
UDB 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 DB2
UDB" (developerWorks, August 2005): This article describes the different user and group
accounts needed to install and work with DB2 UDB for Linux, UNIX, and Windows, Version
8.2 and introduces the DB2 UDB security model, including user authentication, user and
group authorization, and super users.
"DB2 UDB security, Part 2: Understand the DB2 Universal Database security plugins" (developerWorks, December 2005): Learn about the DB2 UDB security plug-ins, a new
feature introduced in Version 8.2. This article explains what the security plug-ins accomplish
and 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 security
mechanisms to customize the DB2 UDB security plug-ins to achieve authentication based on
public key technology.
developerWorks Information Management zone: Find more resources for DB2 UDB
developers 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 directly
from developerWorks.
Discuss
Participate in the discussion forum for this content.
developerWorks blogs: Get involved in the developerWorks community.
Page 26 of 27
ibm.com/developerWorks/
developerWorks
Page 27 of 27