| |
| - A - |
|---|
| _ActAILog |
|
_ActBILog |
|
| _ActBuffer |
|
_ActIndex |
|
| _ActIOFile |
|
_ActIOType |
|
| _ActLock |
|
_ActOther |
|
| _ActPWs |
|
_ActRecord |
|
| _ActServer |
|
_ActSpace |
|
| _ActSummary |
|
_Area |
|
| _AreaExtent |
|
_AreaStatus |
|
| _AreaThreshold |
|
|
|
| |
| - B - |
|---|
| _Block |
|
_BuffStatus |
|
| |
| - C - |
|---|
| _Cache |
|
_Checkpoint |
|
| _Client-Session |
This table records a client authenticated session information. It stores information about the client session and the methods used to authenticate the client. Its primary purpose is to provide additional information for auditing for the purposes of non repudiation, i.e. to provide extra information as to exactly who the user was.
This table is part of a blank empty database as it has other uses beyond auditing. When used for auditing, the client session UUID will be used to associate the authenticated client session with the audit events.
An authenticated client session may not always be available when recording auditing events, e.g. in the case of an appserver connecting to a database outside of the context of an authenticated session.
The data in this table can be sealed with a Message Digest or MAC for non-repudiation.
Note that the data in this table must be copied to the archive database as part of the archive process, but the contents will not be deleted as part of the same process as the client session information could be used for other purposes than auditing.
|
_Code-Feature |
|
| _Codepage |
|
_Collation |
|
| _Connect |
|
_Constraint |
This table holds information about foreign table constraint definitions. |
| _Constraint-Keys |
This table holds information about virtual keys associated with foreign table constraints. |
|
|
| |
| - D - |
|---|
| _Database-Feature |
|
_Db |
|
| _Db-Detail |
This is an extension to the _db database table to hold auditing specific information. The join to _db is on the _Db-guid foreign key. The primary reason to use an additional table for the auditing information is to facilitate multiple record entries to accomodate different database GUIDs, e.g. when copying the contents of this table to an archive database for long term storage where the archive database contains audit data from multiple databases.
Note that the join from the _db table is not physically shown due to the fact that this data is copied with the archive process and therefore the record in the _db table may be for a different database, breaking the referential integrity.
The details in this table provide a meaningful description of the database associated with a GUID and as this is the only means to describe what the database is where the audit data contains entries for multiple databases, the contents of this table must be copied with the audit data.
Additionally this table records the MAC key used to secure / seal the audit data. Without the MAC key the data in the audit table could not be used, and so the MAC key needs to be copied with the audit data. If the MAC key is ever modified for a particular database, then a new database GUID must be created as a database GUID can only ever have a single MAC key. It is the combination of the database GUID and the MAC key that facilitates access to sealed audit data.
Also, if the database GUID ever changes, a new record must be created in this table with the current MAC key and a meaningful description of the database associated with the GUID.
As mentioned above, the contents of this table must be copied as part of the archive process as the data is needed to describe the database / unseal the audit data. The contents however must not be deleted as part of the archive process, only copied to the archive database.
|
_Db-Option |
This tables provides an extension to the _db database table for additional database options (user defined fields). It is joined to the _db table via the _db-recid field as the RECID of the database never changes, whereas the database GUID does, which would result in lost database options.
This is really a generic table to make the _db metadata extensible. The use of option types upto 32,000 are reserved for Progress internal use.
An example entry in this table would be for a database option that controls whether to record authenticated client sessions or not in the _client-session table.
|
| _DbParams |
|
_DbServiceManager |
|
| _DbServiceManagerObjects |
|
_DbStatus |
|
| |
| - F - |
|---|
| _Field |
|
_Field-Trig |
|
| _File |
|
_File-Trig |
|
| _Filelist |
|
|
|
| |
| - I - |
|---|
| _Index |
|
_Index-Field |
|
| _IndexStat |
|
|
|
| |
| - K - |
|---|
| _KeyEvent |
The purpose of this table is to store key events in the database. Key events are events such as database startup parameters, certain error messages, structural changes to the database, utilities run on the database, etc. that provide a history that can be reviewed by tech support. Such a history is useful when diagnosing customer issues especially when the database log file is missing or has been truncated. |
_KeyEvt |
The purpose of this table is to store key events in the database. Key events are events such as database startup parameters, certain error messages, structural changes to the database, utilities run on the database, etc. that provide a history that can be reviewed by tech support. Such a history is useful when diagnosing customer issues especially when the database log file is missing or has been truncated. |
| |
| - L - |
|---|
| _Latch |
|
_License |
|
| _LobStat |
|
_Lock |
|
| _LockReq |
|
_Logging |
|
| |
| - M - |
|---|
| _MstrBlk |
|
_MyConnection |
|
| |
| - P - |
|---|
| _Partition-Set |
This table holds information for managing in a multi-tenant database. |
_Partition-Set-Detail |
This table holds information for managing in a multi-tenant database. |
| |
| - R - |
|---|
| _Repl-Agent |
|
_Repl-AgentActivity |
|
| _Repl-AgentAIStreaming |
|
_Repl-AgentControl |
|
| _Repl-AgentControlActivity |
|
_Repl-InterAgentActivity |
|
| _Repl-Server |
|
_Resrc |
|
| |
| - s - |
|---|
| _sec-authentication-domain |
This table registers the valid authentication system domains for this database that can be used to authenticate or validate the authentication of a user account.
The authentication domain must be for a valid trusted authentication system as defined in the _sec-authentication-system table, e.g. LDAP, RSA, KEON, KERBOS, Internal, etc.
The details in this table are installation specific and will be maintained by the DBA. |
_sec-authentication-system |
The purpose of this table is to define the supported and trusted authentication systems for this database, e.g. LDAP, RSA, KEON, KERBOS, Internal, etc.
If the authentication system is a PAM module plug-in then details of the supported plug-in behavior are also recorded. If the authentication system is not a PAM plug-in then the method is simply a registered and therefore trusted valid authentication system for this database.
An authentication system must be registered in this table and installation specific domain information defined in the _sec-authentication-domain table in order to use this authentication system for application or database access.
This table facilitates the central definition and deployment of the supported authentication systems to simplify the job of the DBA for an installation so that the DBA just has to capture installation specific information for the authentication systems being used.
|
| _sec-granted-role |
This table defines the roles that are granted to specific users or to other roles for the purpose of grouping roles. The _Grantee is therefore either a user or a role.
The SQL standard states that a role cannot be defined with the same name as a user account and vice-versa. This constraint is generally useful and is enforced in all cases, thereby avoiding the need to record whether a granted role is for a user or for a role.
The definition of roles in the _sec-role table is optional as only the role name is required, but if roles are defined then validation will be implemented to ensure that only a valid role is used.
The grant sequence defines the order that any privileges associated with the role should be applied in order to resolve conflicting privileges in multiple granted roles. The grant sequence is not important for SQL roles because in SQL all privileges are positive in nature and therefore conflicts are not an issue. Privileges simply accumulate in SQL for the user and their roles. Despite this the sequence field would still be specified to support the granting of a role to a user multiple times.
A role may be granted according to a pre-determined condition, e.g. the role may only be valid when the user logs into a specific company or module or between certain hours. The grant condition could contain tokens that could be checked at runtime against the authenticated credentials. This concept does not exist in SQL and so for SQL would be ignored.
Specifically to support SQL, when a role is granted to a user or role, it can optionally be specified with admin rights that additionally grant the ability to pass the role onto other users or roles. This concept however could also be useful for non-SQL applications.
|
_sec-granted-role-condition |
This table is not supported for SQL and is only applicable to application defined roles, i.e. roles that do not begin with an underscore. This will not be checked for internal roles.
This table extends the functionality for PVM (4GL client) specific application roles by facilitating the allocation of the role according to a pre-defined set of conditions. The role will therefore only be granted if all of the conditions are true using a logical AND operator. The failing of a grant condition is the equivalent of revoking the role.
Example grant conditions could include only granting the role if the user authenticates to a specific login company, accesses a specific module of the application, or gains access between certain operating hours, etc.
The grant condition attributes could be automatically checked at runtime during authentication against the authenticated credentials and the list of associated roles adjusted accordingly.
|
| _sec-role |
This table defines the roles that are available to control authorized access to resources. The use of roles for authorization provides high scalability by minimizing the need to setup specific permissions against individual user accounts, with restrictions on specific user accounts being the exception case.
The definition of a role in this table is mandatory and a role cannot be granted to a user or other role until it is created in this table. This table therefore provides a registry of the available roles and can be used to validate rules such as the inability for a user to have the same name as a role and the limitation that a user can never authenticate as a role name.
The SQL standard states that a role cannot be defined with the same name as a user account and vice-versa. This constraint is generally useful and is enforced in all cases, thereby avoiding the need to record whether a granted role is for a user or for a role.
The role name will be defined with a namespace to avoid conflicts. The role name will be case insensitive and will be limited to 32 characters.
The role itself can be used as a permission and the fact the user is granted the role can drive authorized behavior. This concept will be used for internal system roles, e.g. a DBA or Audit Administrator. As far as possible however permissions for system roles will be explicit (defined in ACLs). System roles will follow a standard naming convention in that they will all start with an underscore and a code to determine which clients the system role is applicable to as follows;
_SYS - Internal system role applicable to all clients
_PVM - Internal PVM specific role. This role is only valid for 4GL clients
_SQL - Internal SQL specific role. This role is only valid for SQL clients
In addition, for application defined roles they cannot begin with an underscore but can follow a similar convention, namely:
SYS - Application defined role applicable to all clients
4GL - Application defined role applicable to 4GL clients only
SQL - Application defined role applicable to SQL clients only
If there is no such prefix to the role name then it will be assumed to be an application role applicable to all clients.
Note that the above rules are purely a convention and not currently enforced by the database, or the SQL/4GL clients. It is strongly recommended that the convention is followed however to support future migration in the event that behavior is added later that uses this convention.
As mentioned above, the fact a user or role is granted membership of a role can be useful in itself for authorizing actions on resources, but to support a finer level of detailed permissions to be defined, roles can have explicit permissions granted or denied via the _sec-access-control-entry table used to define ACLs.
Sample rolenames could include;
_sys.audit.admin
_sys.audit.archive
_sys.audit.insert
|
_Segments |
|
| _Sequence |
|
_Servers |
|
| _SQL_Properties |
|
_StorageObject |
|
| _Sysattachtbls |
|
_Sysautostats |
This table holds information on statistics. |
| _Sysbigintstat |
|
_Syscalctable |
|
| _Syscharstat |
|
_Syschkcolusage |
|
| _Syschkconstrs |
|
_Syschkconstr_Name_Map |
|
| _Syscolauth |
|
_Syscolstat |
|
| _Sysdatatypes |
|
_Sysdatestat |
|
| _Sysdbauth |
|
_Sysdblinks |
|
| _Sysfloatstat |
|
_Sysidxstat |
|
| _Sysintstat |
|
_Syskeycolusage |
|
| _Sysncharstat |
|
_Sysnumstat |
|
| _Sysnvarcharstat |
|
_Sysprocauth |
This table describes the priviledges granted on stored procedures or UDFs |
| _Sysprocbin |
|
_Sysproccolumns |
|
| _Sysprocedures |
|
_Sysproctext |
|
| _Sysrealstat |
|
_Sysrefconstrs |
|
| _Sysroles |
|
_Sysschemas |
|
| _Sysseqauth |
|
_Syssmintstat |
|
| _SysStatUse |
This table holds information about SQL Autonomous Update Statistics. |
_Syssynonyms |
|
| _Systabauth |
|
_Systblconstrs |
|
| _Systblstat |
|
_Systimestat |
|
| _Systinyintstat |
|
_Systrigcols |
|
| _Systrigger |
|
_Systsstat |
|
| _Syststzstat |
|
_Sysvarcharstat |
|
| _Sysviews |
|
_Sysviews_Name_Map |
|
| |
| - T - |
|---|
| _TableStat |
|
_Tenant |
This table holds information for each tenant in a multi-tenant database. |
| _Trans |
|
_TxeLock |
|
| |
| - U - |
|---|
| _User |
|
_UserIndexStat |
|
| _UserIO |
|
_UserLobStat |
|
| _UserLock |
|
_UserStatus |
|
| _UserTableStat |
|
|
|
| |
| - V - |
|---|
| _View |
|
_View-Col |
|
| _View-Ref |
|
|
|
| |
| - W - |
|---|
| _Word-rule |
|
|
|