October 30, 1998
Announcing Release LWK01.23
This is an important release that includes a number of changes related to system security. The changes include bug fixes, new features and new system behaviors. These changes are the combined result of investigation into a specific customer situation and past requests for changes from other customers.
The general topic of security in LifeWorks Data Entry concerns three areas: 1) control of user access (login); 2) control of privileged operations (Supervisor Functions); and 3) file protection. See the Supervisor Functions and Security page on the Web Site, or the $W/docs/README.SEC on-line document, for a more detailed discussion of these areas. The changes in this release address the operation of Supervisor Functions.
The predecessor of LifeWorks Data Entry, VISION-Data IV, had a single control of Supervisor Functions, the Supervisor Password. LifeWorks Data Entry added OPERATORS,USERID which specifies each operator as a Supervisor or not. Although this information was available to the system, it was not being checked during most Supervisor Function operations.
The menu interface can be used to access Supervisor Functions. If OPERATORS,USERID is not used, then a user had been able to use the menu interface to delete information and NOT be asked for the Supervisor Password, if one is defined. With this release the Supervisor Password must be entered.
For some, but not all, functions if a password was entered unsuccessfully 3 times in a row then this was considered a successful entry of the password.
New System Behaviors
The new default system behavior addresses the use of OPERATORS,USERID with respect to the control of privileged operations (Supervisor Functions). Additional controls, via statements entered into the $W/text/lwoptions file, allow the customer to further fine tune the behavior.
If OPERATORS,USERID is not used, the system has no way of identifying an operator as a Supervisor. In this case, if a Supervisor Password is defined in LWconfig, then it is required to be entered for each operation.
The following table describes the new default system behavior when OPERATORS,USERID is used, and alternative behaviors that can be defined by the customer. The terms Supervisor and Non-Supervisors refer to the “This user is a supervisor.” field, Y or N respectively, in the operator’s record in OPERATORS,USERID.
|Behavior||Statements to use
in $W/text/lwoptions file
|Supervisors can execute Supervisor Functions without being asked for a password, Non-Supervisors are not allowed to execute Supervisor Functions.||This is the new default behavior.|
|Allow all operators to execute Supervisor Functions, Non-Supervisors are asked for the password if it is defined.||NOSUPERVISOR - This statement reverts to the old behavior.|
|Supervisors can execute Supervisor Functions and are asked for the password, Non-Supervisors are not allowed to execute Supervisor Functions.||PASSWORD1|
|Supervisors can execute Supervisor Functions without being asked for a password, Non-Supervisors are asked for the password.||PASSWORD2|
Note: Setting both PASSWORD1 and PASSWORD2 is equivalent to setting NOSUPERVISOR.
Mode M and Mode I are normally used by programmers and supervisors for file editing. These Modes now are considered to be Supervisor Functions and operation will be allowed as described above. Adding EDANYONE to $W/text/lwoptions will allow any user to use these modes as was done prior to LWK01.23.
$EDIT will now require the operator to provide the password for a job when OPEN or CREATE statements involve batches of a password-protected job. As it may be possible for this change to cause a problem with an existing customer procedure, adding NOEDITPASS to $W/text/lwoptions causes $EDIT to operate as it did prior to this release.
New Security Related Features
Logging execution of Supervisor functions (Audit trail)
By placing LOGSUP in the $W/text/lwoptions file, an audit record of the execution of Supervisor Functions are written to the file $W/text/log.sup. See $W/docs/README.SEC for additional details.
Broadcast messages can be logged
MODEBLOGSUP placed in the $W/text/lwoptions file will include any use of the Broadcast feature in the $W/text/log.sup audit trail file.