SirLib security

SirLib security does not directly protect files. Because programmers will be working most of the time in SirPro, a simple way to ensure consistent use of the SirLib/SirPro system is:

1. Make all managed procedure files PUBLIC with low (read-only) privileges.
2. Allocate those procedure files to SirPro with read privileges and to SirLib with update privileges.

This allows programmers to make copies of the procedures they need but not to change anything in the managed files, forcing all updates to go through SirLib. Details on this kind of arrangement are given in SirLib "getting started" steps.

This set up does not force users to use the managed update features of SirPro (that is, it does not prevent users taking "unmanaged" copies of code to use in development work or for models in ad-hoc reports, etc.), but it does ensure that only changes done through the SirPro and SirLib managed update features will get cycled into the production files. Users with access to SirLib can define projects and reconfigure and cutover files. And the SirLib administrator has only to be concerned with protecting user access to the updating functions of SirLib.

SirLib system security

You access the SirLib security screens from option 4 of the SirLib main menu. This section discusses the system settings; the next section discusses the file settings. Access to the security settings is restricted to users defined as file or system Administrators in the Administration screen.

If the main menu Security option is entered with no file specified, the top line of the SIRLIB Security Maintenance screen shows the system default settings, and each subsequent line shows the settings for a file registered to SirLib. The file name is shown at the left of the screen, and a Y character on the System defaults line under a protectable resource tells SirLib to protect the resource. An N or a blank define the resource as not protected.

Changes are not committed unless you press PF12 before leaving the screen.

SirLib system security profile

Protectable SirLib functions are described in the following table. Access to administration functions (main menu option 3) and to procedure locks (main menu option 7) is open to users in the ADMIN SCLASS for the SIRLIB application subsystem, and through the main menu Administration option itself.

Project	The Project Definition List option on the SirLib main menu brings up a screen containing a list of the names of projects that update a specified file. You can define project names and enter comments and documentation associated with them.
Reconfigure	Option 2 on the SirLib main menu performs the actual application or backout of procedure updates.
Cutover	This complex function cleans up update procedures and all Base versions of procedures, and it re-stamps internal comments in procedures that are updated by the change control system. Because this function has global consequences for the file being cutover, it is recommended that the function be secured.
ReSequencing	Administrators can protect the Resequencing feature in SirPro (the Z prefix command). This command builds an update procedure to renumber the internal sequence numbers used to keep track of changes to a procedure. If a great many changes have occurred against a single procedure, this function keeps the system from overflowing the sequence numbers; it is rarely needed. The consequence of resequencing a procedure when a programmer is in the midst of building changes is that the programmer's changes will not validate against the new line numbers.
Report	Access to all SirLib reports is not secured by default, but reports may be secured if a site considers the information private.

SirLib is distributed as a semi-public application subsystem (APSY) with two subsystem user classes (SCLASSes). The only special privilege associated with the ADMIN SCLASS is access to the Administration functions described in Administering system and file profiles.

To run SirLib on an honor-system basis, the initial administrator (the ID that installed SirLib) may enter the SIRLIB Administration screen and set a system default of N for Secure, telling SirLib not to protect functions. Sites that require more security than this should read further.

SirLib security rules

SirLib security works much like the Administration options. Users are granted access to SirLib/SirPro functions at the file level following these rules:

• If SirLib finds Secure is N for the file, no security is in effect, and the user is granted access.
• If Secure is Y for the file, the security settings from the file record are used.
• If SirLib finds the Secure switch set to blank on the file record, it checks the system record setting for Secure.
  • If SirLib defaults to the system record and finds Secure is N, the user is granted access to whatever they request, because security is off for the whole system, and no file override was input.
  • If Secure is Y on the system record, specific settings are checked for the resource being accessed.

For example, if a user attempts to enter the main menu Project Definition List (option 1) for the file XMPLPROC, SirLib looks up the XMPLPROC file information:

• If Secure is N for XMPLPROC, the user is given access, because no SirLib functions are protected for this file.
• If Secure is Y, SirLib checks to see whether the user ID requesting access has authority to access the Project Definition List option in this file.
• If Secure is blank on the XMPLPROC record, SirLib looks up the System defaults value, and it performs the same check as when it finds file-specific information.

If System defaults is Y to protect the function, the user must have file-specific privileges to perform the function on the file. This lets an administrator set only a single system default profile for security, and then have only user privileges to maintain. File-specific overrides of the system profile take effect immediately, and effect all users.

If Secure is N on the Administration screen, all security settings are ignored for the system (if Secure is off in the system profile) or for individual files (if Secure is off in a file profile). Security privileges may still be defined, but SirLib will not pay attention to them. Security can be bypassed in emergencies by turning it off for a file or for the system, and user privileges do not get lost. Secure set to Y on a file record secures a file even when the system default for Secure is N.

The Secure column is display only. The Secure setting is changed in the Administration menu. On this screen, the setting identifies which files will default to the system settings (the settings on the top line), which will use file security settings, and which will ignore security altogether (SECURE set to N).

Files cannot be added to SirLib through the Security screen. Lines after the last registered file are protected on the Security screen. To add a new file to SirLib, define a profile for it first in the Administration Option.

User security for a file

If the main menu Security option is entered with a file specified, then the top line (File:) of the Security Maintenance screen reflects the protected status for the resources for that file. Blanks or N mean that the resource is not protected. Subsequent lines reflect access privileges for users defined to that file.

Maintaining the SirLib user security table

New users may be added in the blank lines at the bottom of the screen (PF8 allows scrolling below the last user until blank lines are displayed). Though this screen looks similar to the Security screen for system settings, the settings on user lines grant access to resources that may be protected.

A Y in the File: line means the resource is protected. A Y in one of the user lines for the same resource grants that user access to the protected resource.

(Any character entered is converted to Y when the user presses the Enter key). Users may be granted access to resources that are not specified as protected, but their privileges are not verified unless the resource is switched to protected in the future. As with the System/File defaults screen, changes on this screen are not committed until the user presses PF10.

See also

• SirLib
• SirLib implementation
• SirLib programmer's reference
• SirLib update example
• SirLib change control
• SirLib security
• SirLib reports
• SirLib configuration options
• SirLib problem resolution
• SIRLIBD record structure
• SirLib "getting started" steps
• SirLib date processing