SirLib security: Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
 
m (more conversion cleanup)
 
(6 intermediate revisions by 2 users not shown)
Line 3: Line 3:
You've been warned.  ..  (Page built by JAL at the SIRIUS VM; file: FUNPGNEW SYSUT2) -->
You've been warned.  ..  (Page built by JAL at the SIRIUS VM; file: FUNPGNEW SYSUT2) -->
<!-- Page name: SirLib security-->
<!-- Page name: SirLib security-->
<var class="product">SirLib</var> security does not directly protect files.
<var class="product">SirLib</var> security does not directly protect files. Because programmers will be working most of the time in <var class="product">SirPro</var>, a simple way to ensure consistent use of the <var class="product">SirLib</var>/<var class="product">SirPro</var> system is:
Because programmers will be working most of the time in <var class="product">SirPro</var>,
<ol>
a simple way to ensure consistent use of the <var class="product">SirLib</var>/<var class="product">SirPro</var> system
<li>Make all managed procedure files <var>PUBLIC</var> with low (read-only) privileges. </li>
is to make all managed procedure files PUBLIC with low (read-only)
privileges, and then to allocate those procedure files to <var class="product">SirPro</var>
with read privileges and to <var class="product">SirLib</var> 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
<var class="product">SirLib</var>.


Details on this sort of conversion are given in [[SirLib "getting started" steps]].
<li>Allocate those procedure files to <var class="product">SirPro</var> with read privileges and to <var class="product">SirLib</var> with update privileges. </li>
</ol>


This does not <i>force</i> users to use the managed update features
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 <var class="product">SirLib</var>. Details on this kind of arrangement are given in [[SirLib "getting started" steps]].
of <var class="product">SirPro</var> (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
<var class="product">SirPro</var> and <var class="product">SirLib</var> managed update features will get cycled into the
production files.
Users with access to <var class="product">SirLib</var> can define projects and
reconfigure and cutover files.
And the <var class="product">SirLib</var> administrator has only
to be concerned with protecting user access to the updating functions
of <var class="product">SirLib</var>.


Protectable functions in <var class="product">SirLib</var> are Changes, Configuration, Cutover and
This set up does not <i>force</i> users to use the managed update features of <var class="product">SirPro</var> (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 <var class="product">SirPro</var> and <var class="product">SirLib</var> managed update features will get cycled into the production files. Users with access to <var class="product">SirLib</var> can define projects and reconfigure and cutover files. And the <var class="product">SirLib</var> administrator has only to be concerned with protecting user access to the updating functions of <var class="product">SirLib</var>.
Reports.
In addition, <var class="product">SirLib</var> security allows administrators to protect
the Resequencing feature in <var class="product">SirPro</var> (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 <var class="product">SirLib</var> apsy, 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.


<b>:SCREEN ID=LIBR16.SirLib System Security profile display</b>
==SirLib system security==
:SD L=01 C=01. ------------- * * * SIRLIB Security Maintenance * * * ---------------------
You access the SirLib security screens from option 4 of the [[SirLib change control|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 [[SirLib change control#Administering system and file profiles|Administration screen]].
 
If the main menu <b>Security</b> option is entered with no file specified, the top line of the <b>SIRLIB Security Maintenance</b> screen shows the system default settings, and each subsequent line shows the
settings for a file registered to <var class="product">SirLib</var>.
The file name is shown at the left of the screen, and a <code>Y</code> character on the <b>System defaults</b> line under a protectable resource tells <var class="product">SirLib</var> to protect the resource.
An <code>N</code> or a blank define the resource as <i>not protected</i>.
<p>
Changes are not committed unless you press PF12 before leaving the screen. </p>
 
<p class="caption" style="width:450px">SirLib system security profile</p>
<p class="figure">[[File:SlibSysSecurity.png|450px]]</p>
 
The <b>Secure</b> column is display only; the column values, described in the following table, may be changed in the <b>SIRLIB Administration</b> screen.
<table>
<tr class="head"><th>File's <b>Secure</b> column value</th><th>Meaning</th></tr>
 
<tr><td>blank</td>
<td>File defaults to the <b>System default</b> setting.</td></tr>
 
<tr><td>Y</td>
<td>File uses SirLib file-specific security settings.
 
<tr><td>N</td>
<td>File ignores security altogether.</td></tr>
</table>
 
Files cannot be added to <var class="product">SirLib</var> through the <b>Security</b> screen. Lines after the last registered file are protected. To add a new file, define a profile for it first using the <b>SIRLIB Administration</b> screen.
 
Protectable <var class="product">SirLib</var> functions are described in the following table. Main menu access to administration functions and to procedure locks is open to users in the <var>ADMIN SCLASS</var> for the <var>SIRLIB</var> application subsystem.


<table class="thJustBold">
<table class="thJustBold">
<tr><th nowrap>Project Definition</th>
<tr><th nowrap>Project</th>
<td>The Project Definition screen, Option 1 on the <var class="product">SirLib</var> main menu, allows the definition of project names, and the entry of comments and documentation associated with them. </td></tr>
<td>The <b>Project Definition List</b> option on the <var class="product">SirLib</var> 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. </td></tr>


<tr><th>Reconfigure</th>
<tr><th>Reconfigure</th>
<td>Option 2 on the <var class="product">SirLib</var> main menu performs the
<td>Option 2 on the <var class="product">SirLib</var> main menu performs the actual application or backout of procedure updates. </td></tr>
actual application or backout of procedure updates. </td></tr>


<tr><th>Cutover</th>
<tr><th>Cutover</th>
<td>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.
<td>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.
<p>
<p>
This function has global consequences for the file being Cutover, and it is recommended that it be secured. </p></td></tr>
Because this function has global consequences for the file being cutover, it is recommended that the function be secured. </p></td></tr>


<tr><th>ReSequencing</th>
<tr><th>ReSequencing</th>
<td>This function is a prefix command in <var class="product">SirPro</var> which builds an update procedure to re-number the internal sequence numbers used to keep track of changes to a procedure.
<td>Administrators can protect the [[SirLib programmer's reference#Z (RESEQUENCE) command|Resequencing]] feature in <var class="product">SirPro</var> (the <var>Z</var> prefix command). This command builds an update procedure to renumber the internal sequence numbers used to keep track of changes to a procedure.  
<p>
<p>
This function isused when a great many changes have occurred against a single
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. </p></td></tr>
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. </p></td></tr>


<tr><th>Reports</th>
<tr><th>Report</th>
<td>Access to all <var class="product">SirLib</var> reports defaults to unsecured, but may be secured if a site considers the information private. </td></tr>
<td>Access to all <var class="product">SirLib</var> reports is not secured by default, but reports may be secured if a site considers the information private. </td></tr>
</table>
</table>


<var class="product">SirLib</var> is distributed as a semi-public application subsystem (APSY) with two subsystem user classes (SCLASSes).
<var class="product">SirLib</var> is distributed as a semi-public application subsystem (APSY) with two subsystem user classes (SCLASSes).
The only special privilege associated with the <var>ADMIN SCLASS</var> is access to
The only special privilege associated with the <var>ADMIN SCLASS</var> is access to the Administration functions described in [[SirLib change control#Administering system and file profiles|Administering system and file profiles]].  
the Administration functions described in the previous section.
<p>
If <var class="product">SirLib</var> is to be run on an honor-system basis, the initial administrator
To run <var class="product">SirLib</var> on an honor-system basis, the initial administrator (the ID that installed <var class="product">SirLib</var>) may enter the <b>SIRLIB Administration</b> screen and set a system default of <code>N</code> for <b>Secure</b>, telling <var class="product">SirLib</var> not to protect functions.
(the ID that installed <var class="product">SirLib</var>) may enter the Administration Option (described in [[SirLib change control]]) and set a system default of <code>N</code> for <var>SECURE</var>, telling <var class="product">SirLib</var> to not protect functions.
Sites that require more security than this should read further. </p>
Sites that require more security than this should read further.


<var class="product">SirLib</var> security works much as the Administration options described in the previous section. Users are granted access to <var class="product">SirLib</var>/<var class="product">SirPro</var>
===SirLib security rules===
functions at the file level:
<p>
<var class="product">SirLib</var> security works much like the Administration options. Users are granted access to <var class="product">SirLib</var>/<var class="product">SirPro</var>
functions at the file level following these rules: </p>
<ul>
<ul>
<li>If <var class="product">SirLib</var> finds the <var>SECURE</var> switch set to blank on the file record, it checks the system record setting for <var>SECURE</var>. </li>
<li>If <var class="product">SirLib</var> finds <b>Secure</b> is <code>N</code> for the file, no security is in effect, and the user is granted access. </li>
 
<li>If <b>Secure</b> is <code>Y</code> for the
file, the security settings from the file record are used. </li>


<li>If <var class="product">SirLib</var> finds <var>SECURE</var> is <code>N<code> for the file, no security is in effect, and the user is granted access. </li>
<li>If <var class="product">SirLib</var> finds the <b>Secure</b> switch set to blank on the file record, it checks the system record setting for <b>Secure</b>.
<ul>
<li>If <var class="product">SirLib</var> defaults to the system record and finds <b>Secure</b> is <code>N</code>, the user is granted access to whatever they request, because security is off for the whole system, and no file override was input. </li>


<li>If <var>SECURE</var> is <code>Y</code> for the
<li>If <b>Secure</b> is <code>Y</code> on the system record, specific settings are checked for the resource being accessed. </li>
file, the security settings from the file record are used. </li>
</ul></li>
</ul>
</ul>


If <var class="product">SirLib</var>
For example, if a user attempts to enter the main menu <b>Project Definition List</b> (option 1) for the file <code>XMPLPROC</code>, <var class="product">SirLib</var> looks up the <code>XMPLPROC</code> file information:
defaults to the system record and finds <var>SECURE</var> is <code>N</code>, the user is granted access to whatever they request, because security is off for the whole system, and no file override was input.
If <var>SECURE</var> is <code>Y</code> on
the system record, specific settings are checked for the resource being
accessed.
 
For instance, if a user attempts to enter Project Definitions (option
1) for the file <code>XMPLPROC</code>, <var class="product">SirLib</var> looks up the <code>XMPLPROC</code> file information:
<ul>
<ul>
<li>If <var>SECURE</var> is <code>n</code> for <code>XMPLPROC</code>, the user is given access because no <var class="product">SirLib</var> functions are protected for this file. </li>
<li>If <b>Secure</b> is <code>N</code> for <code>XMPLPROC</code>, the user is given access, because no <var class="product">SirLib</var> functions are protected for this file. </li>


<li>If <var>SECURE</var> is <code>Y</code>, <var class="product">SirLib</var> checks to see whether the userid requesting access has authority to access the Projects option in this file. </li>
<li>If <b>Secure</b> is <code>Y</code>, <var class="product">SirLib</var> checks to see whether the user ID requesting access has authority to access the <b>Project Definition List</b> option in this file. </li>


<li>If <var>SECURE</var> is blank on the <code>XMPLPROC</code> record, <var class="product">SirLib</var> looks up the system defaults and performs the same check as it does when it found file-specific information.</li>
<li>If <b>Secure</b> is blank on the <code>XMPLPROC</code> record, <var class="product">SirLib</var> looks up the <b>System defaults</b> value, and it performs the same check as when it finds file-specific information.</li>
</ul>
</ul>


If the system defaults are to protect the function, the user must still
If <b>System defaults</b> is <code>Y</code> 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.
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.


<i>Blanks in the system security profile mean that the resource is
If <b>Secure</b> is <code>N</code> on the <b>Administration</b> screen, all security settings are ignored for the system (if <b>Secure</b> is off in the system profile) or for individual files (if <b>Secure</b> is off in a file profile). Security privileges may still be defined, but <var class="product">SirLib</var> will not pay attention to them.
not to be protected.</i>


If <var>SECURE</var> is <code>N</code> 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, <var class="product">SirLib</var> just won't pay attention to them.
Security can be bypassed in emergencies by turning it off for a file or
Security can be bypassed in emergencies by turning it off for a file or
for the system, and user privileges will not be lost.
for the system, and user privileges do not get lost. <b>Secure</b> set to <code>Y</code> on a file record secures a file even when the system default for <b>Secure</b> is <code>N</code>.
<var>SECURE</var> set to <code>Y</code> on a file record will secure a file even when the system default for
<var>SECURE</var> is <code>N</code>.


If the Security option (option 4) is entered without a file specified
==User security for a file==
on the main menu, the top line of the security screen will show the
If the main menu <b>Security</b> option is entered with a file specified, then the top line (<b>File:</b>) of the <b>Security Maintenance</b> screen reflects the protected status for the resources for that file. Blanks or <code>N</code> mean that the resource is
System Default settings, and each subsequent line will show the
<i>not</i> protected. Subsequent lines reflect access privileges for users defined to that file.
settings for a file registered to <var class="product">SirLib</var>.
The filename is shown at the
left of the screen, and the user enters any character under each
protectable resource to tell <var class="product">SirLib</var> to protect the resource.
Blanks on
the top line define a system default of <i>not protected</i> for
that function.
Changes are not committed unless the user presses
PF12 before leaving the screen.
<i>The <b>SECURE</b> column is display only</i>.
The <var>SECURE</var> setting is changed in the Administration menu.
On this screen it tells the user 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 (<var>SECURE</var> set to <code>N</code>).


Files cannot be added to <var class="product">SirLib</var> through the <b>Security</b> screen.
<p class="caption" style="width:450px">Maintaining the SirLib user security table</p>
Lines after the last registered file are protected on the <b>Security</b> screen.
<p class="figure">[[File:SlibFileSecurity.png|450px]]</p>
To add a new file to <var class="product">SirLib</var>, define a profile for it first in the Administration Option.


<b>:SCREEN ID=LIB417.Maintaining User Security Table</b>
New users may be added in the blank lines at the bottom of the screen
:SD L=01 C=01. ----------- * * * SIRLIB File Security Maintenance * * * ----------------
(PF8 allows scrolling below the last user until blank lines are displayed).  


If the Security option is entered with a file specified on the main
<blockquote class="note">
menu, then the top line of the <b>Security</b> screen reflects the protected
<p><b>Note:</b> Though this screen looks similar to the <b>Security</b> screen for system settings, the settings on user lines <i>grant access</i> to resources that may be protected. Although a <code>Y</code> in the <b>File:</b> line means the resource is protected, a <code>Y</code> in one of the user lines for the same resource grants that user access to the protected resource. </p>
status for the resources for that file.
<p>
Subsequent lines reflect access privileges for users defined to that file.
Also, any character you enter for a user is converted to <code>Y</code> when you press the Enter key. You must leave blank the column for a feature the user is <i>not</i> permitted to use.</p>
New users may be added in the blank lines at the bottom of the screen
</blockquote>
(PF8 allows scrolling below the last user until blank lines
are displayed).
Though this screen looks the same as the <b>Security</b> screen for System/File settings, the settings on user lines <i>grant access</i> to resources that may be protected.


A <code>Y</code> in the top line of this screen reflects the resource being
Users may be granted access to resources that are not specified as protected, but their privileges are not verified
protected. A <code>Y</code> in one of the user lines for the same resource
grants that user access to the protected resource.
(Any character entered is converted to <code>Y</code> 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.
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.
Changes on this screen are not committed until the user presses PF12.


==See also==
==See also==

Latest revision as of 00:07, 22 October 2015

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

The Secure column is display only; the column values, described in the following table, may be changed in the SIRLIB Administration screen.

File's Secure column valueMeaning
blank File defaults to the System default setting.
Y File uses SirLib file-specific security settings.
N File ignores security altogether.

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

Protectable SirLib functions are described in the following table. Main menu access to administration functions and to procedure locks is open to users in the ADMIN SCLASS for the SIRLIB application subsystem.

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.

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).

Note: 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. Although 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.

Also, any character you enter for a user is converted to Y when you press the Enter key. You must leave blank the column for a feature the user is not permitted to use.

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.

Changes on this screen are not committed until the user presses PF12.

See also