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 option is restricted to users defined as file or system Administrators in the Administration 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 Administration option itself.

Project Definition	The Project Definition screen, Option 1 on the SirLib main menu, allows the definition of project names, and the entry of 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 is a complex function performed to clean up update procedures and all "BASE." versions of procedures, and to re-stamp internal comments in procedures updated by the change control system. This function has global consequences for the file being Cutover, and it is recommended that it 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.
Reports	Access to all SirLib reports defaults to unsecured, but 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 the previous section. If SirLib is to be run on an honor-system basis, the initial administrator (the ID that installed SirLib) may enter the Administration Option (described in SirLib change control) and set a system default of N for SECURE, telling SirLib to not protect functions. Sites that require more security than this should read further.

SirLib security works much as the Administration options described in the previous section. Users are granted access to SirLib/SirPro functions at the file level:

• If SirLib finds the Secure switch set to blank on the file record, it checks the system record setting for SECURE.
• 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 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 instance, if a user attempts to enter 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 userid requesting access has authority to access the Projects option in this file.
• If SECURE is blank on the XMPLPROC record, SirLib looks up the system defaults and performs the same check as it does when it found file-specific information.

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

Blanks in the system security profile mean that the resource is not to be protected.

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

If the Security option (option 4) is entered without a file specified on the main menu, the top line of the security screen will show the System Default settings, and each subsequent line will show the settings for a file registered to SirLib. The filename is shown at the left of the screen, and you enter any character under each protectable resource to tell SirLib to protect the resource.

Blanks on the top line define a system default of not protected for that function.

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

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 Security option is entered with a file specified on the main menu, then the top line of the Security screen reflects the protected status for the resources for that file. 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 the same as the Security screen for System/File settings, the settings on user lines grant access to resources that may be protected.

A Y in the top line of this screen reflects the resource being 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