Object Rules

IBM defines an object as a named storage space that consists of a set of characteristics that describe it and its data. Thus, an object is anything that occupies space in storage, and on which you can perform operations. Examples of objects include programs, files, libraries, folders, and IFS directories and files. Exit Point Manager allows you to define authority rules to control access at the object level.

You can set rules for libraries and the objects in them, or an IFS path. These rules can be specific to a user (or *PUBLIC) or location and contain the object library, name, and type. Using an object rule, you can define access to both the object and the data contained within the object.

NOTE:
Path strings must begin with a slash (/) and must not begin with any of "QSYS.LIB", "QFileSvr.400", "QOpenSys", "QOPT" or "QNTC". These values are not case sensitive, thus QOPENSYS and qopensys are similarly invalid. Also, the virtual directory names "." and ".." are not allowed in the path. Additionally, there must be at least one character between each slash in the path.

Object rules allow you to specify the operation that the rule allows (*ALL, *CREATE, *READ, *UPDATE, or *DELETE), and the action to take (*REJECT, *OS400, *SWITCH) for data access and object access. Thus, you can define an object rule for a specific user or location, for a specific object, and for a specific type of access. In addition, you can specify values for auditing, capturing transactions, and messaging in your object rules.

Setting rules at the object level provides a different measure of control than setting rules at the user or location levels. For example, you can set one object rule to restrict all users and locations from accessing a specific file (such as payroll) instead of setting multiple rules at the user or location levels to control access.

Object Rules and Exit Point Manager

There is a close relationship between rules in Exit Point Manager. Object rules need *MEMOBJ filter rules to trigger them. When you define an object rule, you select the servers and functions that will enforce the rule. This creates the *MEMOBJ Authority filter rules for the user or location object rule. The *MEMOBJ Authority filter rule tells Exit Point Manager to check memorized transactions (MTR) for authority. If no MTR authority is found, it then checks the transaction against the object rules.

Whenever any rule changes, Exit Point Manager manages the relationships between the filter rules, object rules, and memorized transactions.

If there are no filter rules with *MEMOBJ authority that refer to a particular active object rule, that object rule is set to *INACTIVE by the system.

NOTE:
When there are no more active object rules for a given user or location, you should remove or modify the filter rules for that user or location. When you select to deactivate (for example, by changing or deleting) the last active object rule for a user or location, Exit Point Manager asks you to select how to handle the filter rules that are in place. If you use a command (such as CHGOBJRUL or DLTOBJRUL), you must specify command parameters that define how to handle the filter rules in case they are needed at run time during command processing.

Object Rules and the Remote Command Server

The Remote Command server has some unusual properties. The server only recognizes and reports on object type *CMD, and does not supply any other object type to the server. This means Exit Point Manager cannot identify any other object type to apply to the object rule. Remote Command server Object Rules will not work unless they are for the command itself.

Example:

The following remote command issued from a DOS prompt:

RMTCMD CRTLIB TESTLIB //mysystem

will work if the object rule is for CRTLIB (type *CMD). It will not work for TESTLIB (type *LIB).

Managing Object Lists

Working with Object List Entries

The purpose of an object list is to group the objects in a library that you want to secure in one object list to which you then can apply Exit Point Manager Object Rules. The object list entries specify the objects that you are securing.

Creating rules for an object list using the green screen

You can create rules to control access to the objects listed in an object list from the Work with Object Lists screen. Creating a rule adds filter rules for the user or location specified for the rule.

Example: Blocking access to a library while allowing a specific user to access a specific file within that library

In this example, we will block access to all files in the library PAYROLL but still allow user SHAASE to access the EMPLOYEE file within that library.

To block access using this method, you must change the *PUBLIC rule for *SQLSRV to *MEMOBJ. This instructs Exit Point Manager to consult Object Lists to determine access control. Additional Object Lists will need to be created to authorize access to other objects and libraries using *SQLSVR.