The security log is created and written when security logging is enabled (using the ENABLE SECURITY_AUDIT statement). The security log file has the following format:
Field Name |
Data Type |
Description |
audittime |
Date |
Date and time of the audit event |
User_name |
char(32) |
Effective user name |
Real_name |
char(32) |
Real user name |
userprivileges |
char(32) |
User privileges |
objprivileges |
char(32) |
Object privileges |
database |
char(32) |
Database |
auditstatus |
char(1) |
Status of event; Y for success or N for failure |
auditevent |
char(24) |
Type of event |
objecttype |
char(24) |
Type of object |
objectname |
char(32) |
Name of object |
description |
char(80) |
Text description of event |
objectowner |
char(32) |
Owner of the object being audited |
detailnum |
Integer(4) |
Detail number |
detailinfo |
varchar(256) |
Detail textual information |
sessionid |
char(16) |
Session identifier |
querytext_ sequence |
Integer(4) |
Sequence number for query text records, where applicable |
Note: When registered, a security log is read-only.
To map the columns in the virtual table to the fields in the log file, specify the IS clause in the column list and the field name from the preceding table. For example:
db_name char(32) is 'database'
maps the table column, db_name, to the security log field, database.
At least one column must be specified. If the IS clause is omitted, the column names must correspond to the field names listed in the preceding table. Columns can be specified in any order.
The security log file name must be specified as a quoted string, and must be a valid operating system file specification. To dynamically register whatever log file is in use, specify AS IMPORT FROM CURRENT. If CURRENT is specified, SQL operations on the virtual log table always see the log file in use, even if the physical log file changes.
By default, the security log shows security events for the entire Ingres installation. If the database field is omitted, the security log contains records only for the database in which the log is registered.
The ROWS option in the WITH clause specifies the number of records the log is expected to contain; the default is 1000. This value is displayed by the HELP TABLE statement as Rows:, and is used by the DBMS query optimizer to produce query plans for queries that see the registered table.
The DBMS option specifies the origin of the table being registered. To register a security log, specify SXA.
The WITH clause in an embedded Register Table statement can be specified using a host string variable (with :hostvar).
The session must have the maintain_audit privilege. To query the audit log, the auditor privilege is required.
The Register Table statement locks pages in the iiregistrations, iirelation, iiattributes, and iiaudittables catalogs.
The following example registers a security audit log with various attributes:
REGISTER TABLE aud1 (
audittime date not null,
user_name char(32) not null,
real_name char(32) not null,
userprivileges char(32) not null,
objprivileges char(32) not null,
database char(32) not null,
auditstatus char(1) not null,
auditevent char(24) not null,
objecttype char(24) not null,
objectname char(32) not null,
objectowner char(32) not null,
description char(80) not null,
objectlabel security_label not null,
detailinfo varchar(256) not null,
detailnum integer4 not null,
sessionid char(16) not null,
querytext_sequence integer4 not null
) AS IMPORT FROM 'myfile'
WITH DBMS=sxa; rows=2000