The following table lists the user privileges.

Table 2-1 User privileges

Type of user privilege	Description	What users who have this privilege can do	Who can grant this privilege
			H	D	S
DBA privilege	This privilege is required in order to grant or revoke the DBA, CONNECT, and schema definition privileges.	Grant the DBA, CONNECT, and schema definition privileges to other users. Revoke the DBA, CONNECT, and schema definition privileges of other users. Define schemas for other users. When a schema is defined, the schema's owner can define base tables, view tables, indexes, abstract data types, stored procedures#2 stored functions#2 and triggers. Drop other users' schemas, base tables, view tables, indexes, abstract data types, stored procedures#2 stored functions#2 and triggers. Define items related to the connection security facility. Connect to HiRDB (has the CONNECT privilege).	Y	Y	N
Audit privilege	This privilege must be granted to auditors. Users with this privilege set audit privileges when the security audit facility is being used. For details about the security audit facility, see 24. Using the Security Audit Facility. Users with the audit privilege have the following privileges: CONNECT privilege Schema definition privilege	Access audit trail tables.#1 Load data into audit trail tables. Grant and revoke SELECT privileges for audit trail tables. Delete audit trail tables. Modify the passwords of auditors. Define and delete audit events.	Y	N	N
CONNECT privilege	This privilege is required to use HiRDB. An error results when a user who does not have the CONNECT privilege attempts to use HiRDB.	Connect to databases.	Y	Y	N
Schema definition privilege	This privilege is required to define a schema.	Define your own schema. When a schema is defined, the schema's owner can define base tables, view tables, indexes, abstract data types, stored procedures#2 stored functions#2 and triggers. Drop other users' schemas, base tables, view tables, indexes, abstract data types, stored procedures#2 stored functions#2 and triggers.	Y	Y	N
RDAREA usage privilege	This privilege is required to use a private RDAREA, but is not needed for creating tables and indexes in public RDAREAs.	Create tables and indexes in a private RDAREA.	Y	Y	N
Access privilege	This privilege is required to access tables (base tables and view tables). There are four access privilege types; the types are set at the table level:	Access the tables of other users.	N	N	Y
	SELECT privilege	Search for (SELECT) a table.	N	N	Y
	INSERT privilege	Add (INSERT) row data into a table.	N	N	Y
	DELETE privilege	Delete (DELETE) row data from a table.	N	N	Y
	UPDATE privilege	Update (UPDATE) row data in a table.	N	N	Y

Legend:

H: HiRDB administrator

D: User with DBA privilege

S: Schema owner

Y: Capable of granting privileges

N: Not capable of granting privileges

#1

You cannot add data to or delete data from an audit trail table (INSERT or UPDATE). The CONNECT privilege is not required for use of the directory server linkage facility.

#2

You can also define or delete public procedures and public functions.

The falsification prevention facility is a security function that is provided in addition to the table access privileges. When the falsification prevention option (INSERT ONLY) is specified for a table that is being defined, the defined table becomes a falsification prevented table.

The objectives and features of falsification prevented tables are as follows.

Objectives

• Prevent accidental deletion and updating of data.
• Prevent data from illegal updating and deletion.

Features

• Users with the UPDATE privilege cannot update these tables; even the owners of these tables cannot update them.
• Users with the DELETE privilege cannot delete from these tables data that has not reached the deletion prevention time limit; even the owners of these tables cannot delete such data.
• Users with the INSERT privilege can insert rows into these tables.
• Users with the SELECT privilege can search these tables.

For details about the falsification prevention facility, see the HiRDB Version 9 Installation and Design Guide.

HiRDB supports a facility that registers the results of security-related checking into an audit trail table as an audit trail when an event that accesses a HiRDB resource occurs. This facility is called the security audit facility. An audit trail table records who accessed which resource when, and whether the security check was successful. An audit trail table can be used for auditing illegal accesses.

To prevent illegal modification of audit trail tables, the users who are permitted to operate an audit trail table are limited to those shown in the following table.

Table 2-2 Users who are permitted to operate an audit trail table

Operation on the audit trail table	Permitted users
Referencing of data (SELECT)	Auditor Users who have the SELECT privilege for the audit trail table
Deletion of data (DELETE and PURGE)	Auditor
Addition or modification of data (INSERT or UPDATE)	None

For details about the security audit facility, see 24. Using the Security Audit Facility.