Open System Services Management and Operations Guide (G06.29+, H06.07+)

Managing Security
Open System Services Management and Operations Guide527191-005
8-26
Audit Records for OSS Objects
The OSS name server maintains the absolute pathname of the mount point for each
fileset that it manages. To ensure that they are generated quickly, all pathnames that
are stored in audit records are normalized as follows:
All dots (.), double dots (..), multiple slashes, and symbolic-link references are
resolved.
The maximum length of the stored pathname is 1023 bytes. If the actual pathname
length exceeds 1023 bytes, the audited name consists of three periods (…)
followed by the last 1020 bytes of the pathname.
Which audit records are generated depends on the operation (see Auditing of OSS
Shell Commands on page 8-27 for a list of what is generated in the audit record of
different operations). A record is generated for an object in an audited fileset after the
process that manages the object checks the user ID to determine whether the user has
the authority to perform the requested operation.
When the operation terminates because of an error and a security ruling has not yet
been obtained, no auditing is performed. An operation can also fail after an audit
record is logged.
The name logged in an operation depends on the type of object being audited.
Formats are:
Object Name Changes
When a directory that is on the path to a fileset mount point is renamed, that renaming
is propagated to the fileset mount point on that path. However, this propagation takes
place after the call on the rename function has finished. If an audited operation is
performed on a file in that path before the rename is propagated to the fileset mount
point, the audit record might contain the old pathname rather than the new one.
OSS fileset $ZPMON.Znnnnn:yyyymmddhhmmss, where nnnnn is the
fileset device number and yyyymmddhhmmss is the local civil
time (LCT) when the fileset was created.
Example: $ZPMON.Z00000:19980119152451
OSS regular file
(disk file)
$vol.ZYQnnnnn.Ziiiiiii:ccccccccccc, where nnnnn is
the fileset device number, iiiiiii is the file’s inode number,
and ccccccccccc is the file’s creation version serial number
(CRVSN).
Example: $OSS1.ZYQ00000.Z00004G6:19934568735
Other OSS files
(such as
AF_UNIX
sockets)
$ZPNS.Znnnnn.Ziiiiiii:ccccccccccc, where nnnnn is the
fileset device number, iiiiiii is the file’s inode number, and
ccccccccccc is the file’s CRVSN.
Example: $ZPNS.Z00000.Z00004G5:19387764537