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 to make all managed procedure files PUBLIC with low (read-only) privileges, and then to 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 conversion are given in SirLib "getting started" steps.
This does not force users to use the managed update features of SirPro (that is, it doesn't 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.
Protectable functions in SirLib are Changes, Configuration, Cutover, and Reports. In addition, SirLib security allows administrators to protect the Resequencing feature in SirPro (the Z prefix command). Access to Administration functions (Option 3) and to View/Clear Procedure Locks (Option 7) is via the ADMIN SCLASS for the SIRLIB application subsystem, and through the Administration option itself. Access to the Security option is restricted to users defined as file or system Administrators in the Administration screen.
SirLib System Security profile
| 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 | This function is a prefix command in SirPro which builds an update procedure to re-number the internal sequence numbers used to keep track of changes to a procedure.
This function isused when a great many changes have occurred against a single procedure, to keep the system from overflowing the sequence numbers. It is rarely needed, and the consequences 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
Nfor the file, no security is in effect, and the user is granted access. - If SECURE is
Yfor 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