Model 204 security features: Difference between revisions

From m204wiki
Jump to navigation Jump to search
 
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<div class="toclimit-3">
==Overview==
==Overview==
<p>A variety of security features provide <var class="product">Model&nbsp;204</var> users with protection against unauthorized use of their account names, files, groups, records, fields, procedures, and terminals. This section describes the role of the file manager in maintaining <var class="product">Model&nbsp;204</var> security. </p>
<p>
A variety of security features provide <var class="product">Model&nbsp;204</var> users with protection against unauthorized use of their account names, files, groups, records, fields, procedures, and terminals. This section describes the role of the file manager in maintaining <var class="product">Model&nbsp;204</var> security. </p>
===Additional documentation on security features===
===Additional documentation on security features===
<ul>
<ul>
<li>System manager responsibilities are described in detail in the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide. </li>
<li>System manager responsibilities are described in detail in [[Storing security information (CCASTAT)#Overview|Storing security information (CCASTAT)]].</li>
<li>In addition, Rocket Software has add-on interfaces between <var class="product">Model&nbsp;204</var> and a number of security products. These security interfaces are described in the Rocket <var class="product">Model&nbsp;204</var> Security Interfaces Manual. </li>
<li>Rocket Software has add-on interfaces between <var class="product">Model&nbsp;204</var> and a number of security products. These security interfaces are described in the [[:Category:Security interfaces|Security interfaces]] pages.</li>
 
<li>SSL/TLS security features for Janus products are described in [[Janus Network Security]]. </li>
</ul>
</ul>
===Using the Model 204 password table===
===Using the Model 204 password table===
<p>The <var class="product">Model&nbsp;204</var> password table is the backbone to the security features in <var class="product">Model&nbsp;204</var>. The user must enter a valid password to access the <var class="product">Model&nbsp;204</var> Online, files, groups of files, and subsystems, which in turn affects access to records. The security feature in <var class="product">Model&nbsp;204</var> is not based on a hierarchy, but rather on direct password validation.</p>
<p>
<p>The password table, CCASTAT, is set up by the system manager. When the file manager determines which users or groups of users can have access to what data, then the file manager works with the system manager to correctly set up the password table and file access. </p>
The <var class="product">Model&nbsp;204</var> password table is the backbone to the security features in <var class="product">Model&nbsp;204</var>. The user must enter a valid password to access the <var class="product">Model&nbsp;204</var> Online, files, groups of files, and subsystems, which in turn affects access to records. The security feature in <var class="product">Model&nbsp;204</var> is not based on a hierarchy, but rather on direct password validation.</p>
<p>
The password table, CCASTAT, is set up by the system manager. When the file manager determines which users or groups of users can have access to what data, then the file manager works with the system manager to correctly set up the password table and file access. </p>
===Types of security===
===Types of security===
<p>All <var class="product">Model&nbsp;204</var> security features are optional. A site can support any combination of features. The file manager is primarily responsible for file, group, record, field, and procedure security. Both system and file managers handle terminal security. The file manager's responsibilities are described in this chapter. </p>
<p>
All <var class="product">Model&nbsp;204</var> security features are optional. A site can support any combination of features. The file manager is primarily responsible for file, group, record, field, and procedure security. Both system and file managers handle terminal security. The file manager's responsibilities are described in this topic. </p>
<table>
<table>
<tr class="head">
<tr class="head">
<th>Type of Security</th>
<th>Type of security</th>
<th>Function</th>
<th>Function</th>
</tr>
</tr>
<tr>
<tr>
<td>Login
<td>Login (System manager)</td>
(System manager)</td>
<td>Limits access to the <var class="product">Model&nbsp;204</var> system by requiring an individual user to enter a password when logging in. Only users who enter a valid password can gain access to the system. When a user successfully logs in, specified privileges are granted.
<td>Limits access to the <var class="product">Model&nbsp;204</var> system by requiring an individual user to enter a password when logging in. Only users who enter a valid password can gain access to the system. When a user successfully logs in, specified privileges are granted. See the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide and the <var>[[LOGCTL command (user ID entries)|LOGCTL]]</var> command for modifying user ID entries.</td>
See [[Storing security information (CCASTAT)#Login security|Login security]] and the <var>[[LOGCTL command (user ID entries)|LOGCTL]]</var> command for modifying user ID entries.
</td>
</tr>
</tr>
<tr>
<tr>
<td>[[#File security|File]]
<td>[[#File security|File]] (File manager)</td>
(File manager)</td>
<td>Protects certain types of files by requiring a user to specify a valid file password in the OPEN command or OPEN statement. After successfully opening a file, a user is granted particular privileges pertaining to the data and procedures in that file, as well as a user class number for procedure security, and field-level security access levels.    </td>
<td>Protects certain types of files by requiring a user to specify a valid file password in the OPEN command or OPEN statement. After successfully opening a file, a user is granted particular privileges pertaining to the data and procedures in that file, as well as a user class number for procedure security, and field-level security access levels.    </td>
</tr>
</tr>
<tr>
<tr>
<td>[[#Group security|Group]]
<td>[[#Group security|Group]] (File manager) </td>
(File manager) </td>
<td>Protects certain types of file groups by requiring a user to specify a valid group password in the OPEN command or OPEN statement. When a user successfully opens a permanent group, the user is granted specified privileges that pertain to the files in the group. When opening a temporary group, the user is granted the privileges that all the member files have in common. </td>
<td>Protects certain types of file groups by requiring a user to specify a valid group password in the OPEN command or OPEN statement. When a user successfully opens a permanent group, the user is granted specified privileges that pertain to the files in the group. When opening a temporary group, the user is granted the privileges that all the member files have in common. </td>
</tr>
</tr>
<tr>
<tr>
<td>[[#Record security|Record]]
<td>[[#Record security|Record]] (File manager) </td>
(File manager) </td>
<td>Limits access to particular records in a <var class="product">Model&nbsp;204</var> file. When record security is in effect, a user can retrieve and update only those records stored by the user's login ID or records that other users have agreed to share. </td>
<td>Limits access to particular records in a <var class="product">Model&nbsp;204</var> file. When record security is in effect, a user can retrieve and update only those records stored by the user's login ID or records that other users have agreed to share. </td>
</tr>
</tr>
<tr>
<tr>
<td>[[#Field-level security|Field-level]]
<td>[[#Field-level security|Field-level]] (File manager) </td>
(File manager) </td>
<td>Protects sensitive fields in a <var class="product">Model&nbsp;204</var> file. Field-level security levels are granted when opening a file or group, and they indicate the type of access (for example, READ, UPDATE) to the field that the user is allowed.    </td>
<td>Protects sensitive fields in a <var class="product">Model&nbsp;204</var> file. Field-level security levels are granted when opening a file or group, and they indicate the type of access (for example, READ, UPDATE) to the field that the user is allowed.    </td>
</tr>
</tr>
<tr>
<tr>
<td>[[#Procedure security|Procedure]]
<td>[[#Procedure security|Procedure]] (File manager) </td>
(File manager) </td>
<td>Limits access to the procedures in a file. It indicates whether a user is authorized to access particular procedures and specifies the type of access (for example, DEFINE, DELETE) that the user is allowed in secured procedures.      </td>
<td>Limits access to the procedures in a file. It indicates whether a user is authorized to access particular procedures and specifies the type of access (for example, DEFINE, DELETE) that the user is allowed in secured procedures.      </td>
</tr>
</tr>
<tr>
<tr>
<td>[[#Subsystem security|Subsystem]]
<td>[[#Subsystem security|Subsystem]] (System manager) </td>
(System manager) </td>
<td>Controls the privileges that are assigned to users who enter a subsystem. The system manager assigns users subsystem command privileges and privileges for each file and group in the subsystem. </td>
<td>Controls the privileges that are assigned to users who enter a subsystem. The system manager assigns users subsystem command privileges and privileges for each file and group in the subsystem.     </td>
</tr>
</tr>
<tr>
<tr>
<td>[[#Terminal security|Terminal]]
<td nowrap>[[#Terminal security|Terminal]] (File and system managers) </td>
(File and system managers) </td>
<td>Allows specified login user IDs and specified files and file groups to be accessed only from certain hard-wired terminals. </td>
<td>Allows specified login user IDs and specified files and file groups to be accessed only from certain hard-wired terminals.   </td>
</tr>
</tr>
</table>
</table>
===Multi-factor Authentication - MFA===
<tr>
<td>
Support for logon with Multi-factor authentication (MFA) is also provided with no updates or parameter changes required to Model 204.  MFA does require that one of the three security interfaces, listed below, be linked into the Model 204 nucleus.  Once a userid is provisioned under MFA, the user acquires a token from a client, e.g. IBM Security Verify, installed on the user's mobile device.  That token is then concatenated, with a password or passphrase, to logon to Model 204.  For example: token:password or token:passphrase, where colon (:) is the concatenating character.  That string is passed, unmodified, to the security interface for verification.
<ul>
<li>ACF2
<li>RACF
<li>TopSecret
</ul>
</td>
</tr>
==File security==
==File security==
<p><var class="product">Model&nbsp;204</var> file security features allow you to restrict access to particular files to designated users, as well as to limit the operations that can be performed on those files. Although you are primarily responsible for determining the file security scheme in a <var class="product">Model&nbsp;204</var> system, you can allow users to change a password for a file if you provide them with the appropriate login privileges. </p>
<p>
<p>Security for files opened in a subsystem operates differently. See [[#Subsystem security|Subsystem security]] for more information.</p>
<var class="product">Model&nbsp;204</var> file security features allow you to restrict access to particular files to designated users, as well as to limit the operations that can be performed on those files. Although you are primarily responsible for determining the file security scheme in a <var class="product">Model&nbsp;204</var> system, you can allow users to change a password for a file if you provide them with the appropriate login privileges. </p>
<p>
Security for files opened in a subsystem operates differently. See [[#Subsystem security|Subsystem security]] for more information.</p>
===File manager's responsibilities===
===File manager's responsibilities===
<p>Ordinarily, the file manager determines which files and file parameters to protect from unauthorized access and determines the initial passwords and associated privileges for the files. It is then the system manager's responsibility to add entries for these files to the password table. The password table contains password and privilege information for files, file groups, and login user IDs. Maintaining this table is discussed in the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide. </p>
<p>
<b>Defining access levels for files</b>
Ordinarily, the file manager determines which files and file parameters to protect from unauthorized access and determines the initial passwords and associated privileges for the files. It is then the system manager's responsibility to add entries for these files to the password table. The password table contains password and privilege information for files, file groups, and login user IDs.
<p>The file manager is responsible for defining the default access levels for public and semipublic <var class="product">Model&nbsp;204</var> files. You are also responsible for determining the four access levels that belong with each file or group password. These levels are then added by the system manager.</p>
Maintaining this table is discussed in [[Storing security information (CCASTAT)#Password table data set|Password table data set]]. </p>
====Defining access levels for files====
<p>
The file manager is responsible for defining the default access levels for public and semipublic <var class="product">Model&nbsp;204</var> files. You are also responsible for determining the four access levels that belong with each file or group password. These levels are then added by the system manager.</p>
===File privileges===
===File privileges===
<p>File privileges determine the type of operations that the user is authorized to perform on the file that is being opened. The types of files are:</p>
<p>
File privileges determine the type of operations that the user is authorized to perform on the file that is being opened. The types of files are:</p>
<table>
<table>
<tr class="head">
<tr class="head">
<th>If the file is...</th>
<th>If the file is...</th>
<th>Then <var class="product">Model&nbsp;204</var>...</th>
<th>Then Model 204...</th>
</tr>
</tr>
<tr>
<tr>
<td>Public</td>
<td>Public</td>
<td>Opens the file without asking for a file password and grants the user default file privileges as specified by the PRIVDEF parameter.</td>
<td>Opens the file without asking for a file password and grants the user default file privileges as specified by the <var>PRIVDEF</var> parameter.</td>
</tr>
</tr>
<tr>
<tr>
<td>Semipublic</td>
<td>Semipublic</td>
<td>
<td>Prompts the user to enter a valid password:
<p>Prompts the user to enter a valid password:</p>
<ul>
<ul>
<li>If the user enters a valid password, the user is given the privileges associated with that password. </li>
<li>If the user enters a valid password, the user is given the privileges associated with that password. </li>
<li>If the user does not know the password or enters an incorrect password, the file is still opened but the user is granted the default file privileges associated with the file.</li>
<li>If the user does not know the password or enters an incorrect password, the file is still opened but the user is granted the default file privileges associated with the file.</li>
</ul>
</ul>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td>Private</td>
<td>Private</td>
<td>
<td>Prompts the user to enter a valid password:  
<p>Prompts the user to enter a valid password: </p>
<ul>
<ul>
<li>If the user enters a valid password, the file is opened and the user is granted the privileges associated with that password.       </li>
<li>If the user enters a valid password, the file is opened and the user is granted the privileges associated with that password. </li>
<li>If the user does not know the password or enters an invalid password, the file is not opened. </li>
<li>If the user does not know the password or enters an invalid password, the file is not opened. </li>
</ul>
</ul>
Line 96: Line 134:
</tr>
</tr>
</table>
</table>
<b>OPEN command and OPEN statement</b>
<p>For a discussion of the OPEN command and the way in which a user specifies a password when opening different types of files, refer to the <var class="product">Model&nbsp;204</var> Parameter and Command Reference. The OPEN statement is described in the <var class="book">Rocket Model&nbsp;204 User Language Manual</var>.</p>
====OPEN command and OPEN statement====
<p>
For a discussion of the <var>OPEN</var> command and the way in which a user specifies a password when opening different types of files,
refer to [[OPEN FILE command]] and also see [[Files, groups, and reference context#OPEN statement and OPENC_statement|OPEN statement and OPENC statement]]. </p>


===Creating files with file security===
===Creating files with file security===
<p>When a file is first created with the CREATE command, you can limit access to the file by setting two system parameters, OPENCTL and PRIVDEF, and by asking the system manager to enter one or more file passwords in the password table. Also, the OPENCTL and PRIVDEF parameters can be reset at a later time.</p>
<p>
<p>The following sections provide a further description of file passwords and privileges, as well as the OPENCTL and PRIVDEF parameters.     </p>
When a file is first created with the CREATE command, you can limit access to the file by setting two system parameters, <var>OPENCTL</var> and <var>PRIVDEF</var>, and by asking the system manager to enter one or more file passwords in the password table. Also, the <var>OPENCTL</var> and <var>PRIVDEF</var> parameters can be reset at a later time.</p>
 
<p>
The following sections provide a further description of file passwords and privileges, as well as the <var>OPENCTL</var> and <var>PRIVDEF</var> parameters. </p>
===File passwords and privileges===
===File passwords and privileges===
<p>You can define several passwords for a file. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the file by the user who opens the file with that password.</p>
<p>
<p>If you do not specify values for OPENCTL and PRIVDEF when you create the file, the file is assumed to be a public file that has a full set of default file privileges. This implies that any user can open the file using the OPEN command or OPEN statement without having to enter a file password, and can then retrieve and update data, define and run procedures, or access file parameters.</p>
You can define several passwords for a file. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the file by the user who opens the file with that password.</p>
<b>Creating passwords</b>
<p>
<p>Passwords can be up to eight characters long and cannot contain blanks, commas, or colons. </p>
If you do not specify values for <var>OPENCTL</var> and <var>PRIVDEF</var> when you create the file, the file is assumed to be a public file that has a full set of default file privileges. This implies that any user can open the file using the <var>OPEN</var> command or <var>OPEN</var> statement without having to enter a file password, and can then retrieve and update data, define and run procedures, or access file parameters.</p>
====Creating passwords====
<p>
Passwords can be up to eight characters long and cannot contain blanks, commas, or colons. </p>
===OPENCTL parameter===
===OPENCTL parameter===
<p>The OPENCTL parameter determines whether or not a user must enter a file password when opening the file. Except as specified in the following table, OPENCTL settings can be added together. The first three settings are mutually exclusive and one of them must be included in your OPENCTL specification. The remaining settings in the table are options that you can add to one of the first three settings. </p>
<p>
The <var>OPENCTL</var> parameter determines whether or not a user must enter a file password when opening the file. Except as specified in the following table, <var>OPENCTL</var> settings can be added together. The first three settings are mutually exclusive and one of them must be included in your <var>OPENCTL</var> specification. The remaining settings in the table are options that you can add to one of the first three settings. </p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 116: Line 165:
<th>Password handling</th>
<th>Password handling</th>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'80'</td>
<td align="right">X'80'</td>
<td>Public</td>
<td>Public</td>
<td>
<td>
<p>Password is not requested and the file is opened with default privileges. </p>
<p>
<p>This setting cannot be combined with X'40'.</p>
Password is not requested and the file is opened with default privileges. </p>
<p>
This setting cannot be combined with X'40'.</p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'40'</td>
<td align="right">X'40'</td>
<td>Semipublic</td>
<td>Semipublic</td>
<td>
<td>
<p>User is asked for a password. For a valid password, the user is given the associated privileges. Otherwise, the user is granted default file privileges. </p>
<p>
<p>This setting cannot be combined with X'80'.</p>
User is asked for a password. For a valid password, the user is given the associated privileges. Otherwise, the user is granted default file privileges. </p>
<p>
This setting cannot be combined with X'80'.</p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'00'</td>
<td align="right">X'00'</td>
Line 137: Line 193:
<td>Without a valid password the file is not opened.</td>
<td>Without a valid password the file is not opened.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'20'</td>
<td align="right">X'20'</td>
<td>Using record security</td>
<td>Using record security</td>
<td>
<td>
<p>No effect.</p>
<p>
<p>The user must have a security level that permits some type of access.</p>
No effect.</p>
<p>
The user must have a security level that permits some type of access.</p>
</td>
</td>
</tr>
</tr>
<tr>
<td colspan="3">Additional options for Parallel Query Option (PQO)</td>
<tr class="head">
<th colspan="3">Additional options for Parallel Query Option (PQO)</th>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'08'</td>
<td align="right">X'08'</td>
<td>Accessible remotely without a valid password </td>
<td>Accessible remotely without a valid password </td>
<td>
<td>
<p>For a public file, no password is requested and the file is opened with default privileges.</p>
<p>
<p>For a semipublic file, a password is requested. If the password is missing or invalid, the user is granted default file privileges.</p>
For a public file, no password is requested and the file is opened with default privileges.</p>
<p>For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened if X'02' is set. </p>
<p>
For a semipublic file, a password is requested. If the password is missing or invalid, the user is granted default file privileges.</p>
<p>
For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened if X'02' is set. </p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'04'</td>
<td align="right">X'04'</td>
Line 162: Line 227:
<td><var class="product">Model&nbsp;204</var> permanent group security is in effect. Password handling for local users is unaffected.</td>
<td><var class="product">Model&nbsp;204</var> permanent group security is in effect. Password handling for local users is unaffected.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'02'</td>
<td align="right">X'02'</td>
Line 167: Line 233:
<td>For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened. </td>
<td>For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened. </td>
</tr>
</tr>
<tr>
<tr>
<td align="right">X'00'</td>
<td align="right">X'00'</td>
Line 173: Line 240:
</tr>
</tr>
</table>
</table>
<p>For PQO sites, the OPENCTL parameter determines how a file can be accessed remotely. The PQO remote access settings have no meaning for local files. For more information about PQO remote files, see the Parallel Query Option/204 User's Guide.</p>
<p>
For PQO sites, the OPENCTL parameter determines how a file can be accessed remotely. The PQO remote access settings have no meaning for local files. For more information about PQO remote files, see [[PQO: Remote files and scattered groups]].</p>
 
===PRIVDEF parameter and file privileges===
===PRIVDEF parameter and file privileges===
<p>The PRIVDEF parameter summarizes the default file privileges that are assigned when a public file is opened, or when a semipublic file is opened without a password or with an invalid password. Privileges can be set to any combination of the following bit settings. These privileges are identical to the privileges that can be specified for an individual file password in the password table.      </p>
<p>
The PRIVDEF parameter summarizes the default file privileges that are assigned when a public file is opened, or when a semipublic file is opened without a password or with an invalid password. Privileges can be set to any combination of the following bit settings. These privileges are identical to the privileges that can be specified for an individual file password in the password table.      </p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 181: Line 251:
<th>User can...</th>
<th>User can...</th>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'8000'</td>
<td align="right"> X'8000'</td>
<td>Issue file manager privileged commands such as INITIALIZE, SECURE, and DESECURE. The file manager can also reset file parameters, provided that ad hoc update privileges (X'2000') are obtained. </td>
<td>Issue file manager privileged commands such as INITIALIZE, SECURE, and DESECURE. The file manager can also reset file parameters, provided that ad hoc update privileges (X'2000') are obtained. </td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'4000'</td>
<td align="right"> X'4000'</td>
<td>Override record security; see [[#Record security|Record security]].</td>
<td>Override record security; see [[#Record security|Record security]].</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'2000'</td>
<td align="right"> X'2000'</td>
<td>Update data with ad hoc requests or host language programs.  </td>
<td>Update data with ad hoc requests or host language programs.  </td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'1000'</td>
<td align="right"> X'1000'</td>
<td>Make changes to internal procedures, that is, procedures defined in the same file as the data, but cannot delete them.</td>
<td>Make changes to internal procedures, that is, procedures defined in the same file as the data, but cannot delete them.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0800'</td>
<td align="right"> X'0800'</td>
<td>Update data using internal procedures. </td>
<td>Update data using internal procedures. </td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0400'</td>
<td align="right"> X'0400'</td>
<td>Retrieve data with ad hoc requests or host language programs.</td>
<td>Retrieve data with ad hoc requests or host language programs.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0200'</td>
<td align="right"> X'0200'</td>
<td>Display, echo, and copy internal procedures.</td>
<td>Display, echo, and copy internal procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0100'</td>
<td align="right"> X'0100'</td>
<td>Retrieve data with internal procedures.</td>
<td>Retrieve data with internal procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0080'</td>
<td align="right"> X'0080'</td>
<td>Update data using external procedures, that is, procedures defined in a different file from the data.</td>
<td>Update data using external procedures, that is, procedures defined in a different file from the data.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0040'</td>
<td align="right"> X'0040'</td>
<td>Retrieve data using external procedures.</td>
<td>Retrieve data using external procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0020'</td>
<td align="right"> X'0020'</td>
<td>Include internal procedures.</td>
<td>Include internal procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0010'</td>
<td align="right"> X'0010'</td>
<td>Define internal procedures.</td>
<td>Define internal procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0008'</td>
<td align="right"> X'0008'</td>
<td>Delete internal procedures.</td>
<td>Delete internal procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0001'</td>
<td align="right"> X'0001'</td>
Line 238: Line 322:
</tr>
</tr>
</table>
</table>
<b>PRIVDEF default setting</b>
<p>The default value for the PRIVDEF parameter is X'BFFF', that is, all privileges except the ability to override record security.</p>
====PRIVDEF default setting====
<b>Combining PRIVDEF settings</b>
<p>
<p>Update privileges, for example, update using ad hoc requests, do not imply corresponding retrieval privileges. Thus, a user who has only the ability to update using ad hoc requests (X'2000' bit set) cannot find any records to update. A user must be given both update and retrieval privileges (X'2400') to update data effectively.</p>
The default value for the PRIVDEF parameter is X'BFFF', that is, all privileges except the ability to override record security.</p>
<p>Similarly, privileges for data retrieval using internal procedures (X'0100') do not imply that the user can include a procedure from the file. The X'0020' privilege is required for this.</p>
<p>If procedure security is desired, you must relate procedure class numbers to the procedures stored in the file. Also, determine the field-level security levels for any fields in the file that are particularly sensitive and need to be protected against unauthorized access. Field and procedure security features are discussed in [[#Field-level security|Field-level security]] and [[#Procedure security|Procedure security]].</p>
====Combining PRIVDEF settings====
<p>
Update privileges, for example, update using ad hoc requests, do not imply corresponding retrieval privileges. Thus, a user who has only the ability to update using ad hoc requests (X'2000' bit set) cannot find any records to update. A user must be given both update and retrieval privileges (X'2400') to update data effectively.</p>
<p>
Similarly, privileges for data retrieval using internal procedures (X'0100') do not imply that the user can include a procedure from the file. The X'0020' privilege is required for this.</p>
<p>
If procedure security is desired, you must relate procedure class numbers to the procedures stored in the file. Also, determine the field-level security levels for any fields in the file that are particularly sensitive and need to be protected against unauthorized access. Field and procedure security features are discussed in [[#Field-level security|Field-level security]] and [[#Procedure security|Procedure security]].</p>
===Resetting PRIVDEF or OPENCTL===
===Resetting PRIVDEF or OPENCTL===
<p>When the OPENCTL parameter is reset to X'80' (public), the assigned privileges are those of the current value of the PRIVDEF parameter. This means that if OPENCTL is reset to X'80' while PRIVDEF is set to less than full file manager privileges, you cannot update the file or reset any file parameters. This can also occur if you reset PRIVDEF while OPENCTL is set to X'80'.</p>
<p>
<p>To avoid this problem, use the VIEW PRIVDEF command to ensure that you have appropriate PRIVDEF privileges before you reset OPENCTL to X'80'. Be very careful about resetting PRIVDEF for a public file.</p>
When the OPENCTL parameter is reset to X'80' (public), the assigned privileges are those of the current value of the PRIVDEF parameter. This means that if OPENCTL is reset to X'80' while PRIVDEF is set to less than full file manager privileges, you cannot update the file or reset any file parameters. This can also occur if you reset PRIVDEF while OPENCTL is set to X'80'.</p>
<b>Regaining access</b>
<p>
<p>If you do accidently lock yourself out of a file, you can regain access as follows:</p>
To avoid this problem, use the VIEW PRIVDEF command to ensure that you have appropriate PRIVDEF privileges before you reset OPENCTL to X'80'. Be very careful about resetting PRIVDEF for a public file.</p>
====Regaining access====
<p>
If you do accidently lock yourself out of a file, you can regain access as follows:</p>
<ol>
<ol>
<li>Have the system manager create a permanent private group that contains the locked file.</li>
<li>Have the system manager create a permanent private group that contains the locked file.</li>
<li>Have the system manager add a group password (and tell you that password) to the password table, CCASTAT, with the privileges X'BFFF'.</li>
<li>Have the system manager add a group password (and tell you that password) to the password table, CCASTAT, with the privileges X'BFFF'.</li>
<li>Then, open the private group and issue one of the following commands:</li>
<li>Then, open the private group and issue one of the following commands:
 
<p class="code">IN FILE name RESET OPENCTL=X'40'</p>
<p>
or:</p>
<p class="code">IN FILE name RESET PRIVDEF=X'BFFF'</p>
<p>
where <var class="term">name</var> is the name of the locked file. </p></li>
</ol>
</ol>
<b>IN FILE name RESET OPENCTL=X'40'</b>
<p>or:</p>
<b>IN FILE name RESET PRIVDEF=X'BFFF'</b>
<p>where name is the name of the locked file. </p>
===Securing and desecuring a file===
===Securing and desecuring a file===
<b>Making files secure</b>
<p>Securing a file ensures that a user cannot access a file illegally by running a <var class="product">Model&nbsp;204</var> program with a different password table. A special key in the password table serves as the key for securing a file. The key can be changed by the system manager with the LOGKEY command. When a secured file is opened, <var class="product">Model&nbsp;204</var> compares the key to a copy placed in the file by the SECURE command. The file is opened if the two fields match. If the fields do not match, the user is logged out and an error message is displayed on the operator's console. </p>
====Making files secure====
<p>The SECURE command, which can be issued only by a file manager, provides additional file protection by securing the currently open file. This form of the command is issued without arguments:</p>
<p>
<b>Syntax</b>
Securing a file ensures that a user cannot access a file illegally by running a <var class="product">Model&nbsp;204</var> program with a different password table. A special key in the password table serves as the key for securing a file. The key can be changed by the system manager with the LOGKEY command. When a secured file is opened, <var class="product">Model&nbsp;204</var> compares the key to a copy placed in the file by the SECURE command. The file is opened if the two fields match. If the fields do not match, the user is logged out and an error message is displayed on the operator's console. </p>
<p class="code">SECURE  
<p>
The SECURE command, which can be issued only by a file manager, provides additional file protection by securing the currently open file. This form of the command is issued without arguments:</p>
<p class="syntax">SECURE
</p>
</p>
<b>Desecuring a file</b>
<p>To desecure a previously secured file, issue the command:</p>
====Desecuring a file====
<b>Syntax</b>
<p>
<p class="code">DESECURE  
To desecure a previously secured file, issue the command:</p>
<p class="syntax">DESECURE
</p>
</p>
<p>For a description of using the SECURE and DESECURE commands with procedures, refer to [[#Procedure security|Procedure security]].    </p>
<p>
For a description of using the SECURE and DESECURE commands with procedures, refer to [[#Procedure security|Procedure security]].    </p>
==Group security==
==Group security==
<p>The <var class="product">Model&nbsp;204</var> group security features allow access to particular file groups to be limited to certain users.The file manager is primarily responsible for group security and for the file security features discussed in the preceding section.    </p>
<p>
The <var class="product">Model&nbsp;204</var> group security features allow access to particular file groups to be limited to certain users.The file manager is primarily responsible for group security and for the file security features discussed in the preceding section.    </p>
===Group passwords===
===Group passwords===
<p>Ordinarily, the file manager determines which groups to protect from unauthorized access, and indicates the passwords and associated privileges for these groups. It is then the system manager's responsibility to add entries for these groups to the password table and recommend group parameter settings. The system manager, however, is the only user authorized to create permanent groups. This is done with the CREATE command, which is described in the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide.</p>
<p>
<b>Opening permanent file groups</b>
Ordinarily, the file manager determines which groups to protect from unauthorized access, and indicates the passwords and associated privileges for these groups. It is then
<p>If passwords are required for a permanent file group, only users who know one of the group passwords can open the group. As with file security, the group password determines the types of operations that the user is authorized to perform on the group that is being opened. The privileges associated with the password determine the extent of these operations. Group security operates differently under the Subsystem Management facility. See [[#Subsystem security|Subsystem security]].      </p>
the system manager's responsibility to add entries for these groups to the password table and recommend group parameter settings. The system manager, however, is the only user authorized to create permanent groups.
<b>Opening temporary file groups</b>
This is done with the CREATE command, as described in [[Storing and using file group definitions (CCAGRP)#Creating file groups|Creating file groups]].</p>
<p>Opening a temporary group is functionally equivalent to opening a series of files. Only the user who creates a temporary group can open it. To open a temporary group, the user must be able to open each file in the group individually.</p>
<b>Group file privileges</b>
====Opening permanent file groups====
<p>The types of permanent groups are:</p>
<p>
If passwords are required for a permanent file group, only users who know one of the group passwords can open the group. As with file security, the group password determines the types of operations that the user is authorized to perform on the group that is being opened. The privileges associated with the password determine the extent of these operations. Group security operates differently under the Subsystem Management facility. See [[#Subsystem security|Subsystem security]].      </p>
====Opening temporary file groups====
<p>
Opening a temporary group is functionally equivalent to opening a series of files. Only the user who creates a temporary group can open it. To open a temporary group, the user must be able to open each file in the group individually.</p>
====Group file privileges====
<p>
The types of permanent groups are:</p>
<ul>
<ul>
<li>Public</li>
<li>Public</li>
Line 286: Line 401:
<li>Private      </li>
<li>Private      </li>
</ul>
</ul>
<p>These types are the same as described in [[#File manager's responsibilities|File manager's responsibilities]].</p>
<p>
<p>When a user opens a semipublic or private group, <var class="product">Model&nbsp;204</var> requests that the user enter the password. When the group is opened, the user is granted either the privileges associated with the group password or the default privileges for the group, depending on the password supplied. Default privileges are also supplied when a public group is opened.</p>
These types are the same as described in [[#File manager's responsibilities|File manager's responsibilities]].</p>
<p>
When a user opens a semipublic or private group, <var class="product">Model&nbsp;204</var> requests that the user enter the password. When the group is opened, the user is granted either the privileges associated with the group password or the default privileges for the group, depending on the password supplied. Default privileges are also supplied when a public group is opened.</p>
===Group passwords and privileges===
===Group passwords and privileges===
<p>A permanent group can have several passwords defined for it. Like a file password, a group password can have up to eight characters and cannot contain blanks, commas, or colons. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the group by the user who opens the group with that password. Privileges are expressed as two hexadecimal bytes, as discussed in [[#PRIVDEF parameter and group privileges|PRIVDEF parameter and group privileges]].      </p>
<p>
A permanent group can have several passwords defined for it. Like a file password, a group password can have up to eight characters and cannot contain blanks, commas, or colons. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the group by the user who opens the group with that password. Privileges are expressed as two hexadecimal bytes, as discussed in [[#PRIVDEF parameter and group privileges|PRIVDEF parameter and group privileges]].      </p>
===PRIVDEF parameter and group privileges===
===PRIVDEF parameter and group privileges===
<p>If a value for PRIVDEF and a PUBLIC, SEMIPUB, or PRIVATE specification is not specified at the time that the group is created, the group is assumed to be a PUBLIC group that has default privileges of X'3FFF'. The PRIVDEF parameter, which summarizes the default privileges for a group, provides all the privileges shown for files, plus the two group privileges summarized here. These privileges are identical to the privileges that can be specified for an individual group password in the password table. The X'8000' privilege has no meaning for groups, although it can be important for individual references to member files. </p>
<p>
If a value for PRIVDEF and a PUBLIC, SEMIPUB, or PRIVATE specification is not specified at the time that the group is created, the group is assumed to be a PUBLIC group that has default privileges of X'3FFF'. The PRIVDEF parameter, which summarizes the default privileges for a group, provides all the privileges shown for files, plus the two group privileges summarized here. These privileges are identical to the privileges that can be specified for an individual group password in the password table. The X'8000' privilege has no meaning for groups, although it can be important for individual references to member files. </p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 297: Line 418:
<th>User can...</th>
<th>User can...</th>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0004'</td>
<td align="right"> X'0004'</td>
<td>Update data through procedures from the procedure file.</td>
<td>Update data through procedures from the procedure file.</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'0002'</td>
<td align="right"> X'0002'</td>
Line 306: Line 429:
</tr>
</tr>
</table>
</table>
<p>When a group is created, one of its member files can be designated as the procedure file. This is the file in which procedures for the group are stored and from which procedures are retrieved or deleted. </p>
<p>
<p>In a group context, <var class="term">internal</var> means that a file is a member of the group, while <var class="term">external</var> means that a file is not a member of the group.</p>
When a group is created, one of its member files can be designated as the procedure file. This is the file in which procedures for the group are stored and from which procedures are retrieved or deleted. </p>
<p>
In a group context, <b>internal</b> means that a file is a member of the group, while <b>external</b> means that a file is not a member of the group.</p>
===Determining file and group privileges===
===Determining file and group privileges===
<p>When a command or a User Language statement refers to a file or group, <var class="product">Model&nbsp;204</var> checks the file and group privileges to ensure that the operation is allowed. <var class="product">Model&nbsp;204</var> must determine whether a file has been opened as an individual file, as a member of a permanent or temporary group, or as both.</p>
<p>
<p>The privileges associated with individual files and groups can be granted and combined in different ways, depending upon the [[Files, groups, and reference context#Reference context|reference context]], as shown in the following table. </p>
When a command or a SOUL statement refers to a file or group, <var class="product">Model&nbsp;204</var> checks the file and group privileges to ensure that the operation is allowed. <var class="product">Model&nbsp;204</var> must determine whether a file has been opened as an individual file, as a member of a permanent or temporary group, or as both.</p>
<p>
The privileges associated with individual files and groups can be granted and combined in different ways, depending upon the [[Files, groups, and reference context#Reference context|reference context]], as shown in the following table. </p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 316: Line 444:
<th>User's privileges are...</th>
<th>User's privileges are...</th>
</tr>
</tr>
<tr>
<tr>
<td>Individual file</td>
<td>Individual file</td>
<td>Same as those granted by <var class="product">Model&nbsp;204</var> when the file was opened. These privileges are associated with the specified file password or, if no password is required or is incorrectly specified, the default file privileges.</td>
<td>Same as those granted by <var class="product">Model&nbsp;204</var> when the file was opened. These privileges are associated with the specified file password or, if no password is required or is incorrectly specified, the default file privileges.</td>
</tr>
</tr>
<tr>
<tr>
<td>Temporary or ad hoc group</td>
<td>Temporary or ad hoc group</td>
<td>Intersection of the individual privileges associated with the files that make up the group. <var class="product">Model&nbsp;204</var> compares the privileges of all of the member files; only privileges that are common to every file are granted.  </td>
<td>Intersection of the individual privileges associated with the files that make up the group. <var class="product">Model&nbsp;204</var> compares the privileges of all of the member files; only privileges that are common to every file are granted.  </td>
</tr>
</tr>
<tr>
<tr>
<td>Permanent group</td>
<td>Permanent group</td>
<td>Same as those granted by <var class="product">Model&nbsp;204</var> when the group is opened. These are the privileges associated with the specified group password or, if no password is required or is incorrectly specified, the default group privileges.</td>
<td>Same as those granted by <var class="product">Model&nbsp;204</var> when the group is opened. These are the privileges associated with the specified group password or, if no password is required or is incorrectly specified, the default group privileges.</td>
</tr>
</tr>
<tr>
<tr>
<td>
<td nowrap>Member of a permanent group <br>(<var class="term">not</var> opened individually)
<p>Member of a permanent group</p>
<p>(<var class="term">not</var> opened individually)</p>
</td>
</td>
<td>
<td>Those granted for the group.
<p>Those granted for the group. </p>
<p>
<p>If the file is opened individually, its privileges remain those granted when the file was individually opened.</p>
If the file is opened individually, its privileges remain those granted when the file was individually opened.</p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td>Two permanent groups (<var class="term">not</var> opened as individual files)</td>
<td>Two permanent groups <br>(<var class="term">not</var> opened as individual files)</td>
<td>Union of the privileges associated with the groups. <var class="product">Model&nbsp;204</var> combines the privileges of all open groups of which the file is a member. Any privileges specified for any of the groups are granted.</td>
<td>Union of the privileges associated with the groups. <var class="product">Model&nbsp;204</var> combines the privileges of all open groups of which the file is a member. Any privileges specified for any of the groups are granted.</td>
</tr>
</tr>
<tr>
<tr>
<td>File open as both an individual and a group</td>
<td>File open as both an individual and a group</td>
Line 347: Line 479:
</tr>
</tr>
</table>
</table>
==Record security==
<p>
In addition to protecting an entire file or group from unauthorized access, you can also protect individual records in a file. When record security is in effect for a particular <var class="product">Model&nbsp;204</var> file, each user can be allowed to retrieve and update only records stored in the file with that user's ID or records that other users have agreed to share. The user does not know that any other records exist. </p>
<p>
Record security can be in effect for one or more of the files in a group, but not for the group as a whole. Access to a single record depends on only the record security field defined for the record's file.</p>
===Record security and login security===
<p>
<var class="product">Model&nbsp;204</var> record security can be considered as an extension to login security and cannot be used unless the login security feature is in effect at an installation. Login security is primarily the system manager's responsibility, and it is discussed in detail in [[Storing security information (CCASTAT)#Login security|Login security]]. </p>
===File manager responsibilities===
<p>
Record security usually is the responsibility of the file manager. To initiate record security, set the <var>[[OPENCTL parameter|OPENCTL]]</var> parameter in the <var>CREATE</var> command to indicate that record security is in effect and describe the special record security field in the <var>INITIALIZE</var> command, which is discussed in [[Initializing files#Initializing record security files|Initializing record security files]]. You can turn off record security by using the appropriate <var>OPENCTL</var> setting with the <var>RESET</var> command, but it cannot be turned on by <var>RESET</var>. The file must be defined to have record security through the <var>CREATE</var> command.</p>
===Setting record security for remote users===
<p>
If your site has the Parallel Query Option/204 product, you can control access to remote files with record security using the <var>[[PQOSYS parameter|PQOSYS]]</var> CCAIN system parameter.
If set, <var>PQOSYS</var> creates a special record security key for remote users.
For more information about <var>PQOSYS</var>, see [[PQO: Managing files and groups#Record security for remote users: the PQOSYS parameter|Record security for remote users: the PQOSYS parameter]]. </p>


==Record security==
<p>In addition to protecting an entire file or group from unauthorized access, you can also protect individual records in a file. When record security is in effect for a particular <var class="product">Model&nbsp;204</var> file, each user can be allowed to retrieve and update only records stored in the file with that user's ID or records that other users have agreed to share. The user does not know that any other records exist. </p>
<p>Record security can be in effect for one or more of the files in a group, but not for the group as a whole. Access to a single record depends on only the record security field defined for the record's file.</p>
<b>Record security and login security</b>
<p><var class="product">Model&nbsp;204</var> record security can be considered as an extension to login security and cannot be used unless the login security feature is in effect at an installation. Login security is primarily the system manager's responsibility and is discussed in detail in the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide.</p>
<b>File manager responsibilities</b>
<p>Record security usually is the responsibility of the file manager. To initiate record security, set the OPENCTL parameter in the CREATE command to indicate that record security is in effect and describe the special record security field in the INITIALIZE command, which is discussed in "Initializing record security files". You can turn off record security by using the appropriate OPENCTL setting with the RESET command, but it cannot be turned on by RESET. The file must be defined to have record security through the CREATE command.</p>
<b>Setting record security for remote users</b>
<p>If your site has the Parallel Query Option/204 product, you can control access to remote files with record security using the PQOSYS CCAIN system parameter. If set, PQOSYS creates a special record security key for remote users. For more information about PQOSYS, see the Parallel Query Option/204 User's Guide or the Rocket <var class="product">Model&nbsp;204</var> Parameter and Command Reference.</p>
===Storing and retrieving records===
===Storing and retrieving records===
<p>After a file has been initialized with a record security key, each record stored in the file with a User Language STORE RECORD statement automatically has a record security field added to it, whose value is equal to the current user's login user ID. </p>
<p>
<b>Storing record security fields through File Load or the Host Language Interface</b>
After a file has been initialized with a record security key, each record stored in the file with a SOUL <var>STORE RECORD</var> statement automatically has a record security field added to it, whose value is equal to the current user's login user ID. </p>
<p>For records stored with a Host Language Interface IFBREC or IFSTOR function or by a file load program, a record security field must be added explicitly, along with other fields, when the record is created. For example, the following file load statement adds a record security field:</p>
<p class="code">LDC RECSEC=DARCY=  
====Storing record security fields through File Load or the Host Language Interface====
<p>
For records stored with a Host Language Interface <var>IFBREC</var> or <var>IFSTOR</var> function or by a file load program, a record security field must be added explicitly, along with other fields, when the record is created. For example, the following file load statement adds a record security field:</p>
<p class="code">LDC RECSEC=DARCY=
</p>
</p>
<p>Refer to the File Load chapter for information about the File Load utility.     </p>
<p>
<p>Only records that have a record security field whose value is equal to the current user's login user ID are retrieved by a User Language FIND statement or Host Language Interface calls that perform a find function. If the FILE LOAD statement shown here is executed, for example, only a user logged in under the name DARCY can retrieve these records.  </p>
Refer to [[File Load utility]] for information about the File Load utility. </p>
<p>
Only records that have a record security field whose value is equal to the current user's login user ID are retrieved by a SOUL <var>FIND</var> statement or Host Language Interface calls that perform a find function. If the <var>FILE LOAD</var> statement shown here is executed, for example, only a user logged in under the name <code>DARCY</code> can retrieve these records.  </p>
===Allowing multiple access===
===Allowing multiple access===
<p>To share a record with another user, either you or the user can add an explicit occurrence of the record security field with a value equal to the second user's login user ID. If the second user has update privileges, that user can delete the first value of the record security field, thus making the record accessible only through the second user's user ID.  </p>
<p>
<b>Multiple access in 1NF files</b>
To share a record with another user, either you or the user can add an explicit occurrence of the record security field with a value equal to the second user's login user ID. If the second user has update privileges, that user can delete the first value of the record security field, thus making the record accessible only through the second user's user ID.  </p>
<p>To allow access to record security fields in 1NF files, you must define the record security field as INVISIBLE and REPEATABLE.</p>
====Multiple access in 1NF files====
<p>
To allow access to record security fields in <var>1NF</var> files, you must define the record security field as <var>INVISIBLE</var> and <var>REPEATABLE</var>.</p>
===Overriding record security===
===Overriding record security===
<p>Occasionally, it may be necessary to override the <var class="product">Model&nbsp;204</var> record security scheme. To override record security, you must have the appropriate record security override privileges at login time: the X'04' bit must be set. When the file is opened, the X'4000' bit must be set. </p>
<p>
<p>If both privileges have been granted, you can retrieve all records, regardless of the record security key value associated with them. However, if you store records from User Language at this time, they still have the record security field with the value of your login ID added to them automatically.</p>
Occasionally, it may be necessary to override the <var class="product">Model&nbsp;204</var> record security scheme. To override record security, you must have the appropriate record security override privileges at login time: the X'04' bit must be set. When the file is opened, the X'4000' bit must be set. </p>
<p>If record security was specified for a file in a permanent group, you can override record security for the file if login and group privileges (X'4000') allow it. </p>
<p>
<p>For further information regarding login security bit settings, see the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide. </p>
If both privileges have been granted, you can retrieve all records, regardless of the record security key value associated with them. However, if you store records from User Language at this time, they still have the record security field with the value of your login ID added to them automatically.</p>
<p>
If record security was specified for a file in a permanent group, you can override record security for the file if login and group privileges (X'4000') allow it. </p>
<p>
For further information regarding login security bit settings, see [[Establishing and maintaining security#File security|File security]]. </p>
==Field-level security==
==Field-level security==
<p>Field-level security (FLS) provides an additional level of protection for a user's data by controlling access to the individual fields of a <var class="product">Model&nbsp;204</var> file. It involves a comparison of the user's predetermined numeric access level for a field with the field's own predetermined level, for each of four types of access. Field-level security specifications are put into effect only if access to a data record has been allowed by previous file-level and record-level security checks. The following paragraphs describe in detail how field-level security operates. </p>
<p>
<p>In addition to field-level access for each field, each file has a default access level (that is, all fields within the file are automatically assigned access levels).</p>
Field-level security (FLS) provides an additional level of protection for a user's data by controlling access to the individual fields of a <var class="product">Model&nbsp;204</var> file. It involves a comparison of the user's predetermined numeric access level for a field with the field's own predetermined level, for each of four types of access. Field-level security specifications are put into effect only if access to a data record has been allowed by previous file-level and record-level security checks. The following paragraphs describe in detail how field-level security operates. </p>
<p>The following parameters determine the default field access:</p>
<p>
In addition to field-level access for each field, each file has a default access level (that is, all fields within the file are automatically assigned access levels).</p>
<p>
The following parameters determine the default field access:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 383: Line 544:
<th>Provides this default field access...</th>
<th>Provides this default field access...</th>
</tr>
</tr>
<tr>
<tr>
<td>SELLVL</td>
<td>SELLVL</td>
<td>SELECT </td>
<td>SELECT </td>
</tr>
</tr>
<tr>
<tr>
<td>READLVL</td>
<td>READLVL</td>
<td>READ </td>
<td>READ </td>
</tr>
</tr>
<tr>
<tr>
<td>UPDTLVL</td>
<td>UPDTLVL</td>
<td>UPDATE </td>
<td>UPDATE </td>
</tr>
</tr>
<tr>
<tr>
<td>ADDLVL</td>
<td>ADDLVL</td>
Line 400: Line 565:
</tr>
</tr>
</table>
</table>
<p>Like PRIVDEF, these parameters can be set when a file is created, or they can be reset later. If not explicitly specified, all of these parameters are set to zero, which allows a user to access only unsecured fields (that is, fields with access levels of 0). The same four parameters can be set for a permanent group when it is created by the system manager.</p>
<p>
Like PRIVDEF, these parameters can be set when a file is created, or they can be reset later. If not explicitly specified, all of these parameters are set to zero, which allows a user to access only unsecured fields (that is, fields with access levels of 0). The same four parameters can be set for a permanent group when it is created by the system manager.</p>
===File manager responsibilities===
===File manager responsibilities===
<p>The file manager is responsible for determining the desired field-level security scheme and for assigning security levels to fields that are to be protected. The DEFINE command described in [[ Defining fields manually#Defining fields|Defining fields]] describes the LEVEL option, which allows you to indicate the security level for the field. </p>
<p>
<p>For example, if the following command is issued, only users who have access levels of 70 or greater are allowed to access the PERFORM field, which might contain an employee's performance evaluation code:</p>
The file manager is responsible for determining the desired field-level security scheme and for assigning security levels to fields that are to be protected. The LEVEL option allows you to indicate the security level for the field. </p>
<p class="code">DEFINE FIELD PERFORM WITH LEVEL 70  
<p>
For example, if the following command is issued, only users who have access levels of 70 or greater are allowed to access the PERFORM field, which might contain an employee's performance evaluation code:</p>
<p class="code">DEFINE FIELD PERFORM WITH LEVEL 70
</p>
</p>
===Types of field access===
===Types of field access===
<p>By using the <var class="product">Model&nbsp;204</var> field-level security scheme, you can protect particularly sensitive data fields from unauthorized access. A field can be accessed in several different ways.</p>
<p>
<p>Field-level security features limits access to a field to any combination of the following access types: </p>
By using the <var class="product">Model&nbsp;204</var> field-level security scheme, you can protect particularly sensitive data fields from unauthorized access. A field can be accessed in several different ways.</p>
<p>
Field-level security features limits access to a field to any combination of the following access types: </p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 414: Line 586:
<th>Allows you to...</th>
<th>Allows you to...</th>
</tr>
</tr>
<tr>
<tr>
<td> SELECT</td>
<td>SELECT</td>
<td>Use the field in a User Language FIND statement or in an IFFIND call.</td>
<td>Use the field in a SOUL FIND statement or in an IFFIND call.</td>
</tr>
</tr>
<tr>
<tr>
<td> READ</td>
<td>READ</td>
<td>Examine the value of a field, for example, in a User Language PRINT or assignment statement or an IFGET call. </td>
<td>Examine the value of a field, for example, in a SOUL PRINT or assignment statement or an IFGET call. </td>
</tr>
</tr>
<tr>
<tr>
<td> UPDATE</td>
<td>UPDATE</td>
<td>
<td>Change the value of a previously stored occurrence of a field. This type of access can be granted without a corresponding READ access, which precludes updates of the form shown below:
<p>Change the value of a previously stored occurrence of a field. This type of access can be granted without a corresponding READ access, which precludes updates of the form shown below: </p>
<p class="code">CHANGE <i>fieldname</i> = <i>value</i> TO <i>value</i></p>
<b>CHANGE field_name = value TO value</b>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td> ADD</td>
<td>ADD</td>
<td>
<td>Add new occurrences of a field, including those added by a STORE RECORD statement. This type of access allows data entry clerks or other personnel to add new field occurrences or records without being able to change existing occurrences, or possibly even to examine them.
<p>Add new occurrences of a field, including those added by a STORE RECORD statement. This type of access allows data entry clerks or other personnel to add new field occurrences or records without being able to change existing occurrences, or possibly even to examine them. </p>
<p>
<p>This type of access can also provide a user with the ability to add occurrences of the record security field without altering existing occurrences.</p>
This type of access can also provide a user with the ability to add occurrences of the record security field without altering existing occurrences.</p>
</td>
</td>
</tr>
</tr>
</table>
</table>
<p>Field-level security controls only explicit field references. Implicit references, such as retrieving a record security field with a FIND statement or adding a record security key value with STORE RECORD, are not controlled. </p>
<p>
Field-level security controls only explicit field references. Implicit references, such as retrieving a record security field with a FIND statement or adding a record security key value with STORE RECORD, are not controlled. </p>
===Field levels===
===Field levels===
<p>Every field definition can have a security level associated with it. Security levels are numbered from 0 to 255. 0 implies no security for the field; 255 implies the highest security. </p>
<p>
<b>Field-level security and field ordering</b>
Every field definition can have a security level associated with it. Security levels are numbered from 0 to 255. 0 implies no security for the field; 255 implies the highest security. </p>
<p>In the <var class="product">Model&nbsp;204</var> field-level security scheme, fields can be assigned security levels in a hierarchical fashion. The fields can be ordered in view of the sensitivity of the data that they contain. An example of such an ordering is shown in [[#Field levels|Field levels]], the fields being listed in order of increasing sensitivity.</p>
====Field-level security and field ordering====
<p>
In the <var class="product">Model&nbsp;204</var> field-level security scheme, fields can be assigned security levels in a hierarchical fashion. The fields can be ordered in view of the sensitivity of the data that they contain. An example of such an ordering is shown in [[#Field levels|Field levels]], the fields being listed in order of increasing sensitivity.</p>
<table>
<table>
<caption>Field-level ordering example</caption>
<caption>Field-level ordering example</caption>
Line 448: Line 628:
<th>FLS READ level</th>
<th>FLS READ level</th>
</tr>
</tr>
<tr>
<tr>
<td>Last name</td>
<td>Last name</td>
<td align="right">0</td>
<td align="right">0</td>
</tr>
</tr>
<tr>
<tr>
<td>First name</td>
<td>First name</td>
<td align="right">0</td>
<td align="right">0</td>
</tr>
</tr>
<tr>
<tr>
<td>Employee number</td>
<td>Employee number</td>
<td align="right">0</td>
<td align="right">0</td>
</tr>
</tr>
<tr>
<tr>
<td>City</td>
<td>City</td>
<td align="right">10</td>
<td align="right">10</td>
</tr>
</tr>
<tr>
<tr>
<td>State</td>
<td>State</td>
<td align="right">10</td>
<td align="right">10</td>
</tr>
</tr>
<tr>
<tr>
<td>Zip code</td>
<td>Zip code</td>
<td align="right">10</td>
<td align="right">10</td>
</tr>
</tr>
<tr>
<tr>
<td>Street address</td>
<td>Street address</td>
<td align="right">20</td>
<td align="right">20</td>
</tr>
</tr>
<tr>
<tr>
<td>Position</td>
<td>Position</td>
<td align="right">30</td>
<td align="right">30</td>
</tr>
</tr>
<tr>
<tr>
<td>Telephone number</td>
<td>Telephone number</td>
<td align="right">40</td>
<td align="right">40</td>
</tr>
</tr>
<tr>
<tr>
<td>Salary</td>
<td>Salary</td>
<td align="right">60</td>
<td align="right">60</td>
</tr>
</tr>
<tr>
<tr>
<td>Performance evaluation</td>
<td>Performance evaluation</td>
Line 493: Line 684:
</tr>
</tr>
</table>
</table>
<p>In [[#Field levels|Field levels]], performance evaluation is considered to be the most sensitive field in the record, followed by salary, and so on. Last name, first name, and employee number have not been assigned field-level security numbers. However, file, record, and procedure security features still can be used to control access to those fields.</p>
<p>
In [[#Field levels|Field levels]], performance evaluation is considered to be the most sensitive field in the record, followed by salary, and so on. Last name, first name, and employee number have not been assigned field-level security numbers. However, file, record, and procedure security features still can be used to control access to those fields.</p>
===User levels===
===User levels===
<p>Each user has four field-level security access levels associated with each file and group opened. These correspond to the four field access levels defined previously: SELECT, READ, UPDATE, and ADD. User levels also range from 0 to 255.</p>
<p>
<p>When a user attempts to access a field in a particular way, <var class="product">Model&nbsp;204</var> compares the user's access level with the level assigned for the field. If the user's level for the desired type of access, for example, READ, is greater than or equal to the field's FLS level, the particular type of field access is allowed. </p>
Each user has four field-level security access levels associated with each file and group opened. These correspond to the four field access levels defined previously: SELECT, READ, UPDATE, and ADD. User levels also range from 0 to 255.</p>
<b>User-level security example</b>
<p>
<p>For example, a user who has a READ level of 30 is permitted to print any field that has a READ level between 0 and 30, but cannot print a field that has a higher READ level. Thus, when using the file described above, a user who has a READ level of 30 can print an employee's position (and all fields that have lower FLS fields), but not the employee's telephone number, salary, or performance evaluation. An example of a possible set of access levels at an installation is shown in Table 16-2. </p>
When a user attempts to access a field in a particular way, <var class="product">Model&nbsp;204</var> compares the user's access level with the level assigned for the field. If the user's level for the desired type of access, for example, READ, is greater than or equal to the field's FLS level, the particular type of field access is allowed. </p>
====User-level security example====
<p>
For example, a user who has a READ level of 30 is permitted to print any field that has a READ level between 0 and 30, but cannot print a field that has a higher READ level. Thus, when using the file described above, a user who has a READ level of 30 can print an employee's position (and all fields that have lower FLS fields), but not the employee's telephone number, salary, or performance evaluation. An example of a possible set of access levels at an installation is shown below: </p>
<table>
<table>
<caption>User access levels example</caption>
<caption>User access levels example</caption>
Line 508: Line 705:
<th>ADD</th>
<th>ADD</th>
</tr>
</tr>
<tr>
<tr>
<td>Data entry clerks</td>
<td>Data entry clerks</td>
Line 515: Line 713:
<td align="right">60</td>
<td align="right">60</td>
</tr>
</tr>
<tr>
<tr>
<td>Personnel department clerks</td>
<td>Personnel department clerks</td>
Line 522: Line 721:
<td align="right">0</td>
<td align="right">0</td>
</tr>
</tr>
<tr>
<tr>
<td>Personnel department supervisor</td>
<td>Personnel department supervisor</td>
Line 529: Line 729:
<td align="right">0</td>
<td align="right">0</td>
</tr>
</tr>
<tr>
<tr>
<td>Other employees (for example, telephone operators)</td>
<td>Other employees (for example, telephone operators)</td>
Line 536: Line 737:
<td align="right">0</td>
<td align="right">0</td>
</tr>
</tr>
<tr>
<tr>
<td>Employee supervisor</td>
<td>Employee supervisor</td>
Line 544: Line 746:
</tr>
</tr>
</table>
</table>
<p>The motivations for these assignments easily can be understood in relation to the sample file. Only data entry clerks can add employee records; only supervisors can add performance evaluations; only personnel department supervisors can update salaries, and so on.</p>
<p>
<b>Referring to or displaying fields</b>
The motivations for these assignments easily can be understood in relation to the sample file. Only data entry clerks can add employee records; only supervisors can add performance evaluations; only personnel department supervisors can update salaries, and so on.</p>
<p>When a user's access levels are lower than permitted for the level of a particular field, a reference to the field is treated as a reference to a nonexistent field. Furthermore, the names of such fields are excluded from the output of the DISPLAY FIELD ALL command. Thus, when using the file shown in [[#User levels|User levels]], only personnel and employee supervisors know that a performance evaluation field even exists in the file. The field is never visible to other users.  </p>
<b>Limiting access to fields</b>
====Referring to or displaying fields====
<p>Access to records for particular employees can be controlled in another way. Employee supervisors usually are given a password that allows them to read or add any field in the file. However, procedure- or record-level security can be used to restrict supervisors' access to only the records of their employees.</p>
<p>
When a user's access levels are lower than permitted for the level of a particular field, a reference to the field is treated as a reference to a nonexistent field. Furthermore, the names of such fields are excluded from the output of the DISPLAY FIELD ALL command. Thus, when using the file shown in [[#User levels|User levels]], only personnel and employee supervisors know that a performance evaluation field even exists in the file. The field is never visible to other users.  </p>
=====Limiting access to fields=====
<p>
Access to records for particular employees can be controlled in another way. Employee supervisors usually are given a password that allows them to read or add any field in the file. However, procedure- or record-level security can be used to restrict supervisors' access to only the records of their employees.</p>
===Determining user access levels===
===Determining user access levels===
<p>The access levels assigned for a user are determined when the user opens a file or a group using the OPEN command described in the <var class="product">Model&nbsp;204</var> Parameter and Command Reference, or using the OPEN statement described in the Rocket <var class="product">Model&nbsp;204</var> User Language Manual. Access level assignments are made for various types of files or groups as follows:    </p>
<p>
The access levels assigned for a user are determined when the user opens a file or a group using the
[[OPEN FILE command]], [[OPEN PERM GROUP command]], or [[OPEN TEMP GROUP command]] or using the <var>[[Files, groups, and reference context#OPEN statement and OPENC statement|OPEN]]</var> statement.
Access level assignments are made for various types of files or groups as follows:    </p>
<ul>
<ul>
<li>If a file or a permanent group is public or semipublic and an incorrect password is specified in the OPEN, the user's four access levels are taken from the file or group defaults described in [[#Procedure security|Procedure security]]. </li>
<li>If a file or a permanent group is public or semipublic and an incorrect password is specified in the OPEN, the user's four access levels are taken from the file or group defaults described in [[#Procedure security|Procedure security]]. </li>
<li>If a private or semipublic file or group is opened with a valid password, the user's four access levels are the same as those associated with the password. </li>
<li>If a private or semipublic file or group is opened with a valid password, the user's four access levels are the same as those associated with the password. </li>
<li>If a temporary or ad hoc group is opened, all the member files are opened separately as individual files. Opening these individual files establishes a set of four access levels for each member file.</li>
<li>If a temporary or ad hoc group is opened, all the member files are opened separately as individual files. Opening these individual files establishes a set of four access levels for each member file.</li>
</ul>
</ul>
<b>Access levels for temporary or ad hoc groups</b>
<p>The four access levels for a temporary or ad hoc group are formed by taking the minimum of each access level across all the member files. Suppose that FILEA and FILEB have the access levels shown in the following table.</p>
====Access levels for temporary or ad hoc groups====
<p>
The four access levels for a temporary or ad hoc group are formed by taking the minimum of each access level across all the member files. Suppose that <code>FILEA</code> and <code>FILEB</code> have the access levels shown in the following table.</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 566: Line 781:
<th>ADD</th>
<th>ADD</th>
</tr>
</tr>
<tr>
<tr>
<td>FILEA</td>
<td>FILEA</td>
Line 573: Line 789:
<td align="right"> 0</td>
<td align="right"> 0</td>
</tr>
</tr>
<tr>
<tr>
<td>FILEB</td>
<td>FILEB</td>
Line 581: Line 798:
</tr>
</tr>
</table>
</table>
<p>If a temporary group named FILES, consisting of FILEA and FILEB, is opened, the group is assigned the access levels:</p>
<p>
If a temporary group named <code>FILES</code>, consisting of <code>FILEA</code> and <code>FILEB</code>, is opened, the group is assigned the access levels:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 590: Line 808:
<th>ADD</th>
<th>ADD</th>
</tr>
</tr>
<tr>
<tr>
<td>FILES</td>
<td>FILES</td>
Line 598: Line 817:
</tr>
</tr>
</table>
</table>
<p>This is equivalent to the comparison of file privileges that occurs when opening a temporary or ad hoc group; see [[#Group security|Group security]].</p>
<p>
<b>Examples</b>
This is equivalent to the comparison of file privileges that occurs when opening a temporary or ad hoc group; see [[#Group security|Group security]].</p>
<p>The following examples show how your user access levels for a file can change as the reference context changes. In the examples, the four user-access levels, SELECT, READ, UPDATE, and ADD, are represented by their first letters.</p>
<p>A field reference occurs in single file context, and the file is opened as a single file:</p>
====Examples====
<p>
The following examples show how your user access levels for a file can change as the reference context changes. In the examples, the four user-access levels, SELECT, READ, UPDATE, and ADD, are represented by their first letters.</p>
<p>
A field reference occurs in single file context, and the file is opened as a single file:</p>
<p class="code">                    S      R      U      A
<p class="code">                    S      R      U      A
OPEN FILE FILEA    100    100    10    20
OPEN FILE FILEA    100    100    10    20
BEGIN
BEGIN
   FPC NAME=JONES
   FPC NAME=JONES
END  
END
</p>
</p>
<p>The four access levels used in checking field references (100, 100, 10, 20) are those assigned when FILEA was opened as a single file.</p>
<p>
<p>A field reference occurs in group context:</p>
The four access levels used in checking field references (100, 100, 10, 20) are those assigned when <code>FILEA</code> was opened as a single file.</p>
<p>
A field reference occurs in group context:</p>
<p class="code">                    S      R      U      A
<p class="code">                    S      R      U      A
OPEN FILE GROUPA    50    75    20    0
OPEN FILE GROUPA    50    75    20    0
BEGIN
BEGIN
   FPC NAME=JONES
   FPC NAME=JONES
END  
END
</p>
</p>
<p>The four access levels used for checking field references in any file of the group (50, 75, 20, 0) are the four assigned when the group was opened. All the files in a group receive the same four access levels.</p>
<p>
<p>A field reference occurs in single file context, but the file was opened only as a member of one or more permanent groups. FILEA is a member of the two groups, GROUPA and GROUPB:</p>
The four access levels used for checking field references in any file of the group (50, 75, 20, 0) are the four assigned when the group was opened. All the files in a group receive the same four access levels.</p>
<p>
A field reference occurs in single file context, but the file was opened only as a member of one or more permanent groups. <code>FILEA</code> is a member of the two groups, <code>GROUPA</code> and <code>GROUPB</code>:</p>
<p class="code">                    S      R      U      A
<p class="code">                    S      R      U      A
CLOSE FILE FILEA
CLOSE FILE FILEA
Line 624: Line 851:
  BEGIN
  BEGIN
   IN FILEA FPC NAME=JONES
   IN FILEA FPC NAME=JONES
  END  
  END
</p>
</p>
<p>The four access levels used in checking field references (50, 75, 20, 100) are formed by taking the maximum level defined for the file by every group containing the file that the user has opened. </p>
<p>
The four access levels used in checking field references (50, 75, 20, 100) are formed by taking the maximum level defined for the file by every group containing the file that the user has opened. </p>
 
==Procedure security==
==Procedure security==
<p><var class="product">Model&nbsp;204</var> procedure security limits access to a file's procedures in the following ways:    </p>
<p>
<var class="product">Model&nbsp;204</var> procedure security limits access to a file's procedures in the following ways:    </p>
<ul>
<ul>
<li>By allowing you to specify user privileges that control the type of functions that can be performed on the procedures within a file, for example, to display, define, or delete the procedure.</li>
<li>By allowing you to specify user privileges that control the type of functions that can be performed on the procedures within a file, for example, to display, define, or delete the procedure.</li>
<li>By limiting access to a procedure to only a particular class of users. This is done by assigning a procedure class number to the procedure that is being secured and a user class to the users allowed to manipulate the procedures. </li>
<li>By limiting access to a procedure to only a particular class of users. This is done by assigning a procedure class number to the procedure that is being secured and a user class to the users allowed to manipulate the procedures. </li>
</ul>
</ul>
<p>These security features are discussed in greater detail in the following sections. In addition, [[#File security|File security]] and [[#Group security|Group security]] discuss the privileges that enable users to access the data in a file or group through procedures.</p>
<p>
These security features are discussed in greater detail in the following sections. In addition, [[#File security|File security]] and [[#Group security|Group security]] discuss the privileges that enable users to access the data in a file or group through procedures.</p>
===Accessing procedures===
===Accessing procedures===
<p>At the time a file or group is opened, particular privileges are established that concern the text of the procedures stored in the file or group. These privileges, or access rights, enable a user to manipulate a procedure in any of the following ways:     </p>
<p>
At the time a file or group is opened, particular privileges are established that concern the text of the procedures stored in the file or group. These privileges, or access rights, enable a user to manipulate a procedure in any of the following ways: </p>
<ul>
<ul>
<li>Use the procedure, for example, by specifying it in an INCLUDE command.</li>
<li>Use the procedure, for example, by specifying it in an INCLUDE command.</li>
<li>Display and copy the procedure. This includes echoing the procedure and using the EDIT command to display or copy it. </li>
<li>Display and copy the procedure. This includes echoing the procedure and using the EDIT command to display or copy it. </li>
<li>Change the procedure, usually with the Editor.</li>
<li>Change the procedure, usually with the Editor.</li>
<li>Define a new procedure in the file with the PROCEDURE command or the Editor. </li>
<li>Define a new procedure in the file with the PROCEDURE command or the Editor. </li>
<li>Delete a procedure by means of the DELETE command. </li>
<li>Delete a procedure by means of the DELETE command. </li>
</ul>
</ul>
<p>The basic procedure functions and commands are discussed in detail in the <var class="book">Rocket Model&nbsp;204 User Language Manual</var>.</p>
<p>
 
For information about the basic procedure functions, see the $Prc* and $Proc* functions in [[List of $functions]]; and for information about procedure related commands, see [[:Category:Commands]].</p>
===Securing procedures===
===Securing procedures===
<p>The privileges established for procedure access discussed in [[#PRIVDEF parameter and file privileges|PRIVDEF parameter and file privileges]] are used to limit the way in which the procedures associated with a file or group can be accessed. <var class="product">Model&nbsp;204</var> provides an additional facility that allows particular procedures to be secured and thus protected from unauthorized access. </p>
<p>
The privileges established for procedure access discussed in [[#PRIVDEF parameter and file privileges|PRIVDEF parameter and file privileges]] are used to limit the way in which the procedures associated with a file or group can be accessed. <var class="product">Model&nbsp;204</var> provides an additional facility that allows particular procedures to be secured and thus protected from unauthorized access. </p>
===User and procedure classes===
===User and procedure classes===
<p>You can limit user access to procedures by assigning user classes that have access to procedures in a particular procedure class.</p>
<p>
<p>User and procedure classes are usually put in place as part of the security scheme for a file or group. Although every user and procedure could have a distinct class number (UCLASS and PCLASS), this approach is too complex and cumbersome for most installations. Thus, sets of procedures and users more often are handled together. </p>
You can limit user access to procedures by assigning user classes that have access to procedures in a particular procedure class.</p>
<b>User classes (UCLASS)</b>
<p>
<p>Examples of typical user classes are:</p>
User and procedure classes are usually put in place as part of the security scheme for a file or group. Although every user and procedure could have a distinct class number (UCLASS and PCLASS), this approach is too complex and cumbersome for most installations. Thus, sets of procedures and users more often are handled together. </p>
====User classes (UCLASS)====
<p>
Examples of typical user classes are:</p>
<ul>
<ul>
<li>All employees in a department</li>
<li>All employees in a department</li>
Line 657: Line 902:
<li>All data entry personnel </li>
<li>All data entry personnel </li>
</ul>
</ul>
<b>Procedure classes (PCLASS)</b>
<p>Examples of typical procedure classes include procedures that:</p>
====Procedure classes (PCLASS)====
<p>
Examples of typical procedure classes include procedures that:</p>
<ul>
<ul>
<li>Display salary data</li>
<li>Display salary data</li>
Line 665: Line 912:
<li>Access sensitive fields in files </li>
<li>Access sensitive fields in files </li>
</ul>
</ul>
<p>Procedure classes and user classes are arbitrary numbers that range from 1 to 255. Their only significance is in their relationship to each other. The numbers are assigned as described in [[#User and procedure classes|User and procedure classes]].</p>
<p>
<p>When a user opens a file or group, the user is given the privileges and user class determined by the OPEN: </p>
Procedure classes and user classes are arbitrary numbers that range from 1 to 255. Their only significance is in their relationship to each other. The numbers are assigned as described in [[#User and procedure classes|User and procedure classes]].</p>
<p>
When a user opens a file or group, the user is given the privileges and user class determined by the OPEN: </p>
<ul>
<ul>
<li>If the file or group is opened with a password, the user class is obtained from the password table, where it is stored with the privilege bytes and field-level security levels for the password.  
<li>If the file or group is opened with a password, the user class is obtained from the password table, where it is stored with the privilege bytes and field-level security levels for the password.
<p>The user class normally is provided by the file manager and entered into the password table by the system manager, as discussed in the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide. </p>
<p>
The user class normally is provided by the file manager and entered into the password table by the system manager, as discussed in [[Storing security information (CCASTAT)#Password table maintenance|Password table maintenance]]. </p>
</li>
</li>
<li>If the file or group is opened without a password, the user is granted default privileges and a default user class. This default user class is the value of the PRCLDEF system parameter, which has a default value of zero and can be set by the file manager.    </li>
<li>If the file or group is opened without a password, the user is granted default privileges and a default user class. This default user class is the value of the PRCLDEF system parameter, which has a default value of zero and can be set by the file manager.    </li>
</ul>
</ul>
<b>Relationship between user and procedure classes</b>
<p>An access control table (ACT) stored in each file assigns to particular user classes the access rights to particular procedure classes. These mappings from user class to procedure class in the ACT are created using the SECURE command described in [[#SECURE command, definition format|SECURE command, definition format]]. </p>
====Relationship between user and procedure classes====
<p>The user class established for a group applies to all its member files. If a file is opened only as part of a permanent group, any reference to a secured procedure compares the user class specified for the group against the procedure's class to determine the available access rights. </p>
<p>
<b>Example</b>
An access control table (ACT) stored in each file assigns to particular user classes the access rights to particular procedure classes. These mappings from user class to procedure class in the ACT are created using the SECURE command described in [[#SECURE command, definition format|SECURE command, definition format]]. </p>
<p>The association of user classes and procedure classes can be explained best by an example: </p>
<p>
<p>Suppose that a user whose user class is 8 includes a procedure named CENTEST, which has a procedure class of 20. <var class="product">Model&nbsp;204</var> must determine whether users of class 8 are allowed to include procedures of class 20. </p>
The user class established for a group applies to all its member files. If a file is opened only as part of a permanent group, any reference to a secured procedure compares the user class specified for the group against the procedure's class to determine the available access rights. </p>
<p>If <var class="product">Model&nbsp;204</var> checks the ACT in the file in which CENTEST is defined and finds that an INCLUDE is permitted, the procedure is included. </p>
<p>If, however, INCLUDE is not permitted for users of class 8, the INCLUDE does not take place and an error message is issued. </p>
=====Example=====
<p>This mapping of user and procedure classes is discussed in greater detail in the sections that follow.</p>
<p>
<b>Assigning procedure classes</b>
The association of user classes and procedure classes can be explained best by an example: </p>
<p>A procedure class can be specified for a procedure by the file manager or by an individual user. The class can be assigned:</p>
<p>
Suppose that a user whose user class is 8 includes a procedure named <code>CENTEST</code>, which has a procedure class of 20. <var class="product">Model&nbsp;204</var> must determine whether users of class 8 are allowed to include procedures of class 20. </p>
<p>
If <var class="product">Model&nbsp;204</var> checks the ACT in the file in which <code>CENTEST</code> is defined and finds that an INCLUDE is permitted, the procedure is included. If, however, INCLUDE is not permitted for users of class 8, the INCLUDE does not take place and an error message is issued. </p>
<p>
This mapping of user and procedure classes is discussed in greater detail in the sections that follow.</p>
====Assigning procedure classes====
<p>
A procedure class can be specified for a procedure by the file manager or by an individual user. The class can be assigned:</p>
<ul>
<ul>
<li>By the user when defining the procedure with the PROCEDURE command</li>
<li>By the user when defining the procedure with the PROCEDURE command</li>
<li>By the file manager when securing the procedure with the SECURE command  </li>
<li>By the file manager when securing the procedure with the SECURE command  </li>
</ul>
</ul>
<b>User-defined procedure classes</b>
<p>When defining a procedure, the user can specify a procedure class number in the following format:</p>
=====User-defined procedure classes=====
<b>Syntax</b>
<p>
<p class="code">PROCEDURE <var class="term">name</var> PCLASS=<var class="term">n</var>  
When defining a procedure, the user can specify a procedure class number in the following format:</p>
<p class="syntax">PROCEDURE <span class="term">name</span> PCLASS=<span class="term">n</span>
</p>
</p>
<p>where:</p>
<p>
<p>n is any number in the range 1 through 255.</p>
Where:</p>
<p>A user's access rights to procedures are checked first at the file level and then at the procedure level. Thus, if the user is to be allowed to change a secured procedure, the user must have procedure update file privileges, and the appropriate entry must have been made in the ACT.</p>
<p>
<b>File manager-defined procedure classes</b>
<var class="term">n</var> is any number in the range 1 through 255.</p>
<p>File manager-defined procedure classes are discussed in the following sections, in context of the commands that the file manager uses for this purpose.</p>
<p>
A user's access rights to procedures are checked first at the file level and then at the procedure level. Thus, if the user is to be allowed to change a secured procedure, the user must have procedure update file privileges, and the appropriate entry must have been made in the ACT.</p>
=====File manager-defined procedure classes=====
<p>
File manager-defined procedure classes are discussed in the following sections, in context of the commands that the file manager uses for this purpose.</p>
===SECURE command, definition format===
===SECURE command, definition format===
<p>If you have appropriate file manager privileges, you can use the SECURE command in the following form to:</p>
<p>
If you have appropriate file manager privileges, you can use the SECURE command in the following form to:</p>
<ul>
<ul>
<li>Secure both files and procedures</li>
<li>Secure both files and procedures</li>
Line 705: Line 973:
<li>Make entries in the access control table</li>
<li>Make entries in the access control table</li>
</ul>
</ul>
<p>The format is:</p>
<p>
<b>Syntax</b>
The format is:</p>
<p class="code">SECURE [PROCEDURE]  
   NAME=<var class="term">procname</var> [,<var class="term">procname</var> ...] PCLASS=<var class="term">pclass</var>  
<p class="syntax">SECURE [PROCEDURE]
   NAME=<span class="term">procname</span> [,<span class="term">procname</span> ...] PCLASS=<span class="term">pclass</span>
</p>
</p>
<p>where:</p>
<p>
<p>procname is the name of an existing procedure to be secured.</p>
Where:</p>
<p>pclass is the procedure class number to assign to the procedure(s); the number must be in the range 1 to 255. </p>
<ul>
<p>The SECURE command must be issued in file context, that is, the current default must be a file, not a group.</p>
<li><var class="term">procname</var> is the name of an existing procedure to be secured.</li>
<b>Example</b>
<li><var class="term">pclass</var> is the procedure class number to assign to the procedure(s); the number must be in the range 1 to 255. </li>
<p>The following example is a SECURE command used to secure a procedure:</p>
<li>The SECURE command must be issued in file context, that is, the current default must be a file, not a group.</li>
<p class="code">SECURE PROCEDURE NAME = PAY PCLASS = 7  
</ul>
====Example====
<p>
The following example is a SECURE command used to secure a procedure:</p>
<p class="code">SECURE PROCEDURE NAME = PAY PCLASS = 7
</p>
</p>
<p>After this command is issued, the procedure PAY is secured with the procedure class number 7. An entry for PCLASS=7 is made in the procedure dictionary. If PAY is currently secured, its old procedure class is changed to the new class.</p>
<p>
After this command is issued, the procedure PAY is secured with the procedure class number 7. An entry for PCLASS=7 is made in the procedure dictionary. If PAY is currently secured, its old procedure class is changed to the new class.</p>
===SECURE command, mapping format===
===SECURE command, mapping format===
<p>The SECURE command lets you map particular access privileges and user classes to particular procedure classes. This command creates entries in the access control table. Issue the following form of the command:</p>
<p>
<b>Syntax</b>
The SECURE command lets you map particular access privileges and user classes to particular procedure classes. This command creates entries in the access control table. Issue the following form of the command:</p>
<p class="code">SECURE [PROCEDURE]
   ACCESS = {ALL | (access [,access...]) | NONE}
<p class="syntax">SECURE <span class="squareb">[</span>PROCEDURE<span class="squareb">]</span>
   UCLASS = {ALL | (uclass [,uclass...])}
   ACCESS = <span class="squareb">{</span>ALL <span class="squareb">|</span> (<span class="term">access</span> <span class="squareb">[</span>,<span class="term">access</span>...<span class="squareb">]</span>) <span class="squareb">|</span> NONE<span class="squareb">}</span>
   PCLASS = {ALL | (pclass [,pclass...])}
   UCLASS = <span class="squareb">{</span>ALL <span class="squareb">|</span> (<span class="term">uclass</span> <span class="squareb">[</span>,<span class="term">uclass</span>...<span class="squareb">]</span>)<span class="squareb">}</span>
   PCLASS = <span class="squareb">{</span>ALL <span class="squareb">|</span> (<span class="term">pclass</span> <span class="squareb">[</span>,<span class="term">pclass</span>...<span class="squareb">]</span>)<span class="squareb">}</span>
</p>
</p>
<p>where:</p>
<p>
<p>access is a particular privilege associated with the procedures in the procedure class. It can be one of the following:  </p>
Where:</p>
<ul>
<li><var class="term">access</var> is a particular privilege associated with the procedures in the procedure class. It can be one of the following:   
<table>
<table>
<tr class="head">
<tr class="head">
Line 734: Line 1,013:
<th>Users can...</th>
<th>Users can...</th>
</tr>
</tr>
<tr>
<tr>
<td>USE </td>
<td>USE </td>
<td>Include procedures.</td>
<td>Include procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td>COPY </td>
<td>COPY </td>
<td>Display and edit (copy only) procedures.</td>
<td>Display and edit (copy only) procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td>CHANGE </td>
<td>CHANGE </td>
<td>Edit procedures.</td>
<td>Edit procedures.</td>
</tr>
</tr>
<tr>
<tr>
<td>DEFINE </td>
<td>DEFINE </td>
<td>Create new procedures (PROCEDURE and EDIT).</td>
<td>Create new procedures (PROCEDURE and EDIT).</td>
</tr>
</tr>
<tr>
<tr>
<td>DELETE </td>
<td>DELETE </td>
<td>Delete procedures.</td>
<td>Delete procedures.</td>
</tr>
</tr>
</table>
</table></li>
<p>uclass is the user class number whose users have access to the procedures in PCLASS; the number must be in the range 1 to 255. Parentheses are optional in the uclass definition.</p>
<li><var class="term">uclass</var> is the user class number whose users have access to the procedures in PCLASS; the number must be in the range 1 to 255. Parentheses are optional in the uclass definition.</li>
<p>pclass is the procedure class number to which users in UCLASS have access; the number must be in the range 1 to 255. Parentheses are optional in the pclass definition. </p>
 
<b>Example</b>
<li><var class="term">pclass</var> is the procedure class number to which users in UCLASS have access; the number must be in the range 1 to 255. Parentheses are optional in the pclass definition. </li>
<p>In the following example, only users in the Payroll Department (user class 90) are allowed to use procedures that manipulate salary fields in a file (procedure class 20 and 30):</p>
</ul>
<p class="code">SECURE PROC ACCESS = (USE) UCLASS = 90 PCLASS = 20,30  
====Example====
<p>
In the following example, only users in the Payroll Department (user class 90) are allowed to use procedures that manipulate salary fields in a file (procedure class 20 and 30):</p>
<p class="code">SECURE PROC ACCESS = (USE) UCLASS = 90 PCLASS = 20,30
</p>
</p>
<p>The entries in the ACT do not take effect for users that have the file open when the SECURE command is issued until they reopen the file. This includes the user who issues the command. The complete syntax and description of the SECURE command is located in the <var class="product">Model&nbsp;204</var> Parameter and Command Reference.</p>
<p>
<p>To complete procedure security implementation, the system manager updates the password table using the LOGCTL command to assign user classes to the appropriate passwords.  </p>
The entries in the ACT do not take effect for users that have the file open when the <var>SECURE</var> command is issued until they reopen the file. This includes the user who issues the command. See [[SECURE PROCEDURE ACCESS command]] for the complete syntax and description of the <var>SECURE</var> command.</p>
<p>
To complete procedure security implementation, the system manager updates the password table using the <var>LOGCTL</var> command to assign user classes to the appropriate passwords.  </p>
===Procedure-related commands and required privileges===
===Procedure-related commands and required privileges===
<p>The following list is a summary of <var class="product">Model&nbsp;204</var> procedure or procedure-related commands that require particular privileges. All these commands are described in the <var class="product">Model&nbsp;204</var> Parameter and Command Reference.  </p>
<p>
The following list is a summary of <var class="product">Model&nbsp;204</var> procedure or procedure-related commands that require particular privileges. All these commands are described in the <var class="product">Model&nbsp;204</var> Parameter and Command Reference.  </p>
<table>
<table>
<caption>Privileges for procedure or procedure-related commands</caption>
<caption>Privileges for procedure or procedure-related commands</caption>
Line 771: Line 1,063:
<th colspan="2">Required privileges</th>
<th colspan="2">Required privileges</th>
</tr>
</tr>
<tr>
<tr>
<td>INCLUDE</td>
<td>INCLUDE</td>
Line 776: Line 1,069:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>EDIT</td>
<td>EDIT</td>
Line 781: Line 1,075:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>DISPLAY</td>
<td>DISPLAY</td>
Line 786: Line 1,081:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>DELETE</td>
<td>DELETE</td>
Line 791: Line 1,087:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>ASSIGN</td>
<td>ASSIGN</td>
Line 796: Line 1,093:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>DEASSIGN</td>
<td>DEASSIGN</td>
Line 801: Line 1,099:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<tr>
<td>RENAME</td>
<td>RENAME</td>
Line 806: Line 1,105:
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tr>
<tr>
<td>Command</td>
<tr class="head">
<td>New procedure</td>
<th>Command</th>
<td>Old procedure</td>
<th>New procedure</th>
<th>Old procedure</th>
</tr>
</tr>
<tr>
<tr>
<td>PROCEDURE</td>
<td>PROCEDURE</td>
Line 816: Line 1,117:
<td>CHANGE</td>
<td>CHANGE</td>
</tr>
</tr>
<tr>
<tr>
<td>
<td>EDIT commands:
<p>EDIT commands:</p>
<p>
<p>GO
GO<br>END</p></td>
  END</p>
<td>DEFINE, USE* DEFINE</td>
</td>
<td>CHANGE, USE* CHANGE</td>
<td>
DEFINE, USE*
DEFINE</td>
<td>
CHANGE, USE*
CHANGE</td>
</tr>
</tr>
<tr>
<tr>
<td colspan="3">*COPY privileges are required in addition to USE to echo text lines of a procedure to a journal.</td>
<td></td>
<td colspan="2">*COPY privileges are required in addition to USE to echo text lines of a procedure to a journal.</td>
</tr>
</tr>
</table>
</table>
===Displaying user and procedure classes===
===Displaying user and procedure classes===
<p>The SECURE command constructs entries in the access control table for any user classes specified in the UCLASS clause. </p>
<p>
The SECURE command constructs entries in the access control table for any user classes specified in the UCLASS clause. </p>
<p class="note"><b>Note:</b> It is important to display procedure security and save it before reorganizing a file, so that you can reestablish the same security. You might have to upgrade your file manager privileges to include COPY, which is not part of the default privileges of a file manager.</p>
<p class="note"><b>Note:</b> It is important to display procedure security and save it before reorganizing a file, so that you can reestablish the same security. You might have to upgrade your file manager privileges to include COPY, which is not part of the default privileges of a file manager.</p>
<p>To determine a user's access rights for various procedure classes, issue the following form of the DISPLAY command: </p>
<p>
<b>Syntax</b>
To determine a user's access rights for various procedure classes, issue the following form of the DISPLAY command: </p>
<p class="code">DISPLAY [PROCEDURE (PRIVILEGES [,NOUSE])
 
   [ALL | UCLASS = <var class="term">uclass</var>[,<var class="term">uclass</var>...]]  
<p class="syntax">DISPLAY [PROCEDURE (PRIVILEGES [,NOUSE])
   [ALL <span class="squareb">|</span> UCLASS = <var class="term">uclass</var>[,<var class="term">uclass</var>...]]
</p>
</p>
<p>where:</p>
<p>
<p>ALL displays information for all user classes. </p>
Where:</p>
<p>uclass displays information only for the specified classes.</p>
<ul>
<p>If neither is specified, your current class and privileges are displayed. </p>
<li>ALL displays information for all user classes. </li>
<p>Privileges are displayed in the following format:</p>
 
<p class="code">UCLASS=<var class="term">u
<li><var class="term">uclass</var> displays information only for the specified classes.</li>
</var> PCLASS=<var class="term">pc</var>,X'<var class="term">nn</var>'
 
<li>If neither is specified, your current class and privileges are displayed.  
<p>
Privileges are displayed in the following format:</p>
<p class="syntax">UCLASS=<var class="term">u</var> PCLASS=<var class="term">pc</var>,X'<var class="term">nn</var>'
       .
       .
       .
       .
Line 853: Line 1,158:
  PCLASS=<var class="term">pc</var>,X'<var class="term">nn</var>'
  PCLASS=<var class="term">pc</var>,X'<var class="term">nn</var>'
</p>
</p>
<p>where:</p>
<p>
<p>u is the user class.</p>
Where:</p>
<p>pc is a procedure class defined for that user class.</p>
<ul>
<p>nn is a privilege byte constructed from combinations of the following bit settings:</p>
<li><var class="term">u</var> is the user class.</li>
 
<li><var class="term">pc</var> is a procedure class defined for that user class.</li>
 
<li><var class="term">nn</var> is a privilege byte constructed from combinations of the following bit settings:
<table>
<table>
<tr class="head">
<tr class="head">
Line 862: Line 1,171:
<th>Privilege</th>
<th>Privilege</th>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'80' </td>
<td align="right"> X'80' </td>
<td>USE</td>
<td>USE</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'40' </td>
<td align="right"> X'40' </td>
<td>COPY</td>
<td>COPY</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'20' </td>
<td align="right"> X'20' </td>
<td>CHANGE </td>
<td>CHANGE </td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'10' </td>
<td align="right"> X'10' </td>
<td>DEFINE</td>
<td>DEFINE</td>
</tr>
</tr>
<tr>
<tr>
<td align="right"> X'08' </td>
<td align="right"> X'08' </td>
<td>DELETE</td>
<td>DELETE</td>
</tr>
</tr>
</table>
</table></li>
<p>If NOUSE is specified, information is displayed at your terminal even if a USE command preceded the DISPLAY command. The device specified by the USE command is not used but is left open.</p>
</ul></li>
<p>See the discussion of other DISPLAY command capabilities in [[ Field display and message broadcast#Overview|Overview]].</p>
 
<li>If NOUSE is specified, information is displayed at your terminal even if a USE command preceded the DISPLAY command. The device specified by the USE command is not used but is left open.</li>
</ul>
<p>
See the discussion of other DISPLAY command capabilities in [[ Field display and message broadcast#Overview|Overview]].</p>
===Sample security scheme===
===Sample security scheme===
<p>A simplified example of a security scheme at an installation is presented in this section. At this installation, the following access rules are established:</p>
<p>
A simplified example of a security scheme at an installation is presented in this section. At this installation, the following access rules are established:</p>
<ul>
<ul>
<li>Most users are allowed to include all secured procedures.</li>
<li>Most users are allowed to include all secured procedures.</li>
<li>Only programmers in the data processing department are allowed to define procedures. However, they cannot use them. These programmers can have user classes 8 or 9.</li>
<li>Only programmers in the data processing department are allowed to define procedures. However, they cannot use them. These programmers can have user classes 8 or 9.</li>
<li>Only users in the payroll department are allowed to use procedures that manipulate salary fields in the file. Payroll users are assigned class 90, and the payroll procedures are in procedure classes 20 and 30.</li>
<li>Only users in the payroll department are allowed to use procedures that manipulate salary fields in the file. Payroll users are assigned class 90, and the payroll procedures are in procedure classes 20 and 30.</li>
<li>Other users are assigned user classes 25, 30, or 31.</li>
<li>Other users are assigned user classes 25, 30, or 31.</li>
<li>Other procedures are in procedure classes 40, 50, 60, or 70. </li>
<li>Other procedures are in procedure classes 40, 50, 60, or 70. </li>
</ul>
</ul>
===Sample SECURE commands===
===Sample SECURE commands===
<p>To create the security scheme in this example, issue the following commands:</p>
<p>
<p class="code"><var>SECURE PROC ACCESS=(CHANGE,DEFINE,DELETE,COPY) UCLASS=8,9 PCLASS=20,30,40,50,60,70
To create the security scheme in this example, issue the following commands:</p>
<p class="code">SECURE PROC ACCESS=(CHANGE,DEFINE,DELETE,COPY) UCLASS=8,9 PCLASS=20,30,40,50,60,70
SECURE PROC ACCESS=(USE) UCLASS=90 PCLASS=20,30
SECURE PROC ACCESS=(USE) UCLASS=90 PCLASS=20,30
SECURE PROC ACCESS=(USE) UCLASS=25,30,31,90 -
SECURE PROC ACCESS=(USE) UCLASS=25,30,31,90 -
   PCLASS=40,50,60,70</var>
   PCLASS=40,50,60,70
</p>
</p>
<b>Importance of SECURE command order</b>
<p>In this example, the order of the SECURE commands is unimportant. However, the order becomes significant when a UCLASS=ALL or PCLASS=ALL clause is included in the command. UCLASS=ALL affects only user classes already mentioned in the ACT. This might be completely different from the list of user classes that actually can be assigned to users from the password table or default file or group settings.</p>
====Importance of SECURE command order====
<p>When PCLASS=ALL is included in the command, no new entries are added to the ACT. Instead, for each user class in the UCLASS list, access rights for each procedure class already mentioned for that user are replaced by the new ACCESS rights. Again, the classes affected in the ACT may be completely different from those actually used for secured procedures in the file. </p>
<p>
In this example, the order of the SECURE commands is unimportant. However, the order becomes significant when a UCLASS=ALL or PCLASS=ALL clause is included in the command. UCLASS=ALL affects only user classes already mentioned in the ACT. This might be completely different from the list of user classes that actually can be assigned to users from the password table or default file or group settings.</p>
<p>
When PCLASS=ALL is included in the command, no new entries are added to the ACT. Instead, for each user class in the UCLASS list, access rights for each procedure class already mentioned for that user are replaced by the new ACCESS rights. Again, the classes affected in the ACT may be completely different from those actually used for secured procedures in the file. </p>
===Changing and adding access privileges===
===Changing and adding access privileges===
<p>Suppose, in this sample security, that the payroll users now need to be able to display all the procedures that they use. Also, suppose that a new set of procedures (of class 15) is developed that all users (including the programmers) can include. The following commands are issued in the order shown to modify the ACT entries already built:</p>
<p>
<p class="code"><var>SECURE PROC ACCESS=(USE) UCLASS=ALL PCLASS=15
Suppose, in this sample security, that the payroll users now need to be able to display all the procedures that they use. Also, suppose that a new set of procedures (of class 15) is developed that all users (including the programmers) can include. The following commands are issued in the order shown to modify the ACT entries already built:</p>
SECURE PROC ACCESS=(USE,COPY) UCLASS=90 PCLASS=ALL </var>
<p class="code">SECURE PROC ACCESS=(USE) UCLASS=ALL PCLASS=15
SECURE PROC ACCESS=(USE,COPY) UCLASS=90 PCLASS=ALL  
</p>
</p>
<p>If these commands are reversed, the payroll users cannot display members of the new class of procedures.</p>
<p>
If these commands are reversed, the payroll users cannot display members of the new class of procedures.</p>
===Removing procedure security for procedures or user classes===
===Removing procedure security for procedures or user classes===
<p>To remove the procedure access defined for user class/procedure class pairs, use the DESECURE command:</p>
<p>
To remove the procedure access defined for user class/procedure class pairs, use the DESECURE command:</p>
<ol>
<ol>
<li>Remove the security for the procedure involved. </li>
<li>Remove the security for the procedure involved. </li>
<li>Delete the procedure class number assigned to the procedure in the procedure dictionary by issuing the form of the DESECURE command immediately below. </li>
<li>Delete the procedure class number assigned to the procedure in the procedure dictionary by issuing the form of the DESECURE command immediately below. </li>
</ol>
</ol>
<b>Note</b>
<p class="note"><b>Note:</b>
<p>If you do not do this, no one can access the procedure, even though the entry might have been removed from the ACT (see the second form of DESECURE below). </p>
If you do not do this, no one can access the procedure, even though the entry might have been removed from the ACT (see the second form of DESECURE below). </p>
<p>Only file managers can issue the DESECURE command and it must be issued in file context (that is, the current default must be a file, not a group). </p>
<p>
<p>The format of the DESECURE command is:</p>
Only file managers can issue the DESECURE command and it must be issued in file context (that is, the current default must be a file, not a group). </p>
<b>Syntax</b>
<p>
<p class="code">DESECURE <var>PROC</var>EDURE {ALL  
The format of the DESECURE command is:</p>
                    | NAME=(<var class="term">procname</var>[,<var class="term">procname</var>...])}
<p class="syntax">DESECURE <b>PROC</b>EDURE {ALL <span class="squareb">|</span> NAME=(<span class="term">procname</span>[,<span class="term">procname</span>...])}
</p>
</p>
<p>where:</p>
<p>
<p>procname is the name of an existing secured procedure.</p>
Where:</p>
<p>To remove particular access privileges for particular procedure classes, use the following form of the DESECURE command to delete entries from the ACT. You must specify either UCLASS or PCLASS, or both.</p>
<p>
<p>The format is:</p>
<var class="term">procname</var> is the name of an existing secured procedure.</p>
<b>Syntax</b>
<p>
<p class="code">DESECURE <var>PROC</var>EDURE
To remove particular access privileges for particular procedure classes, use the following form of the DESECURE command to delete entries from the ACT. You must specify either UCLASS or PCLASS, or both.</p>
   {[UCLASS= {ALL | (uclass[,uclass...])}] |
<p>
     [PCLASS= {ALL | (pclass[,pclass...])}]}
The format is:</p>
<p class="syntax">DESECURE <var>PROC</var>EDURE
   {[UCLASS= {ALL <span class="squareb">|</span> (uclass[,uclass...])}] <span class="squareb">|</span>
     [PCLASS= {ALL <span class="squareb">|</span> (pclass[,pclass...])}]}
</p>
</p>
<p>where:</p>
<p>
Where:</p>
<ul>
<ul>
<li>uclass is the number of an existing user class whose users have access to the procedure in <var class="term">pclass</var>; the number must be in the range 1-255. If only UCLASS is specified, all references to the specified user classes are removed from the ACT.
<li><var class="term">uclass</var> is the number of an existing user class whose users have access to the procedure in <var class="term">pclass</var>; the number must be in the range 1-255. If only UCLASS is specified, all references to the specified user classes are removed from the ACT.
<p>Parentheses are optional with <var class="term">uclass</var>.</p>
<p>
Parentheses are optional with <var class="term">uclass</var>.</p>
</li>
</li>
<li>pclass is the number of an existing procedure class to which users in <var class="term">uclass</var> have access; the number must be in the range 1-255. If only <var class="term">pclass</var> is specified, all references to the specified procedure classes are removed from the ACT.
<p>Parentheses are optional with <var class="term">pclass</var>. </p>
<li><var class="term">pclass</var> is the number of an existing procedure class to which users in <var class="term">uclass</var> have access; the number must be in the range 1-255. If only <var class="term">pclass</var> is specified, all references to the specified procedure classes are removed from the ACT.
<p>
Parentheses are optional with <var class="term">pclass</var>. </p>
</li>
</li>
</ul>
</ul>
===Desecuring both UCLASS and PCLASS===
===Desecuring both UCLASS and PCLASS===
<p>If both UCLASS and PCLASS are specified, the entries for all combinations of the specified user and procedure class pairs are removed from the ACT. For example:</p>
<p>
<p class="code">DESECURE PROC UCLASS=8,9 PCLASS=1,2,3  
If both UCLASS and PCLASS are specified, the entries for all combinations of the specified user and procedure class pairs are removed from the ACT. For example:</p>
<p class="code">DESECURE PROC UCLASS=8,9 PCLASS=1,2,3
</p>
</p>
<p>removes access entries for:</p>
<p>
removes access entries for:</p>
<p class="code">UCLASS 8 and PCLASS 1
<p class="code">UCLASS 8 and PCLASS 1
UCLASS 8 and PCLASS 2
UCLASS 8 and PCLASS 2
Line 953: Line 1,298:
UCLASS 9 and PCLASS 2
UCLASS 9 and PCLASS 2
UCLASS 9 and PCLASS 3
UCLASS 9 and PCLASS 3
</p>
   
   
</p>
===System manager responsibilities===
===System manager responsibilities===
<p>The final step in the desecuring process is to have the system manager remove the password(s) with associated uclasses from the password table. If they are not removed, you must remember not to use them when opening the file.</p>
<p>
The final step in the desecuring process is to have the system manager remove the password(s) with associated uclasses from the password table. If they are not removed, you must remember not to use them when opening the file.</p>
===Privileges required===
===Privileges required===
<p>You must have file-level privileges of at least X'A000' (file manager and ad hoc data update) to issue SECURE and DESECURE commands. In this case, you actually need update but not retrieve privileges. (Refer to [[#File security|File security]] for a discussion of these privileges.)    </p>
<p>
You must have file-level privileges of at least X'A000' (file manager and ad hoc data update) to issue SECURE and DESECURE commands. In this case, you actually need update but not retrieve privileges. (Refer to [[#File security|File security]] for a discussion of these privileges.)    </p>
===File and group references===
===File and group references===
<p>When an explicit reference is made to a file with an IN clause and that file is opened only as a member of one or more permanent groups, the file-level privileges to be checked must be obtained from the group privileges, as defined for every group of which the file is a member. If any group's privileges allow the access in question, then the operation proceeds.</p>
<p>
<p>If the access is to a secured procedure, for every group in which the file is opened and the access is allowed by the group privileges, the user's user class in that group is used to determine privileges for that procedure's class. If any group's user class has the privilege, the operation proceeds.</p>
When an explicit reference is made to a file with an IN clause and that file is opened only as a member of one or more permanent groups, the file-level privileges to be checked must be obtained from the group privileges, as defined for every group of which the file is a member. If any group's privileges allow the access in question, then the operation proceeds.</p>
<p>See the discussion of reference context in the example on [[#Determining user access levels|Determining user access levels]] and the Rocket <var class="product">Model&nbsp;204</var> User Language Manual for more information. </p>
<p>
If the access is to a secured procedure, for every group in which the file is opened and the access is allowed by the group privileges, the user's user class in that group is used to determine privileges for that procedure's class. If any group's user class has the privilege, the operation proceeds.</p>
<p>
See the discussion of reference context in the example on [[#Determining user access levels|Determining user access levels]] and see [[Files, groups, and reference context]] for more information. </p>
==Subsystem security==
==Subsystem security==
<p>When a user enters a subsystem, <var class="product">Model&nbsp;204</var> opens and determines privileges for all subsystem files and groups for that user. The files that are opened and the privileges that are assigned are based on a combination of the user's subsystem user class and the subsystem's status, both specified by the system manager in the subsystem definition. </p>
<p>
<p>The system manager assigns a user to a subsystem user class by entering the user's <var class="product">Model&nbsp;204</var> login user ID in the appropriate subsystem user class. Whenever the user invokes the subsystem, the user is assigned the subsystem command privileges and the file and group privileges of that subsystem user class.  </p>
When a user enters a subsystem, <var class="product">Model&nbsp;204</var> opens and determines privileges for all subsystem files and groups for that user. The files that are opened and the privileges that are assigned are based on a combination of the user's subsystem user class and the subsystem's status, both specified by the system manager in the subsystem definition. </p>
<p>The system manager controls access to the subsystem through the subsystem status: public, semipublic, or private. The status determines which user classes can enter a particular subsystem and whether or not users without a user class assignment are permitted entry. </p>
<p>
<p>For more information about subsystems, see the Subsystem Management facility description in the Rocket <var class="product">Model&nbsp;204</var> System Manager's Guide.</p>
The system manager assigns a user to a subsystem user class by entering the user's <var class="product">Model&nbsp;204</var> login user ID in the appropriate subsystem user class. Whenever the user invokes the subsystem, the user is assigned the subsystem command privileges and the file and group privileges of that subsystem user class.  </p>
<p>
The system manager controls access to the subsystem through the subsystem status: public, semipublic, or private. The status determines which user classes can enter a particular subsystem and whether or not users without a user class assignment are permitted entry. </p>
<p>
For more information about subsystems, see [[System requirements for Application Subsystems]].</p>
 
==Terminal security==
==Terminal security==
<p><var class="product">Model&nbsp;204</var> terminal security allows access to certain login user IDs, files, or groups to be restricted to users at certain terminals. For example, you might want a particular MEDICAL file to be accessible only through terminals located physically in doctors' offices.    </p>
<p>
<p>The terminal security feature allows a list of terminal numbers to be associated with each login, file, or group password. A terminal number is determined during <var class="product">Model&nbsp;204</var> initialization by the order of the user parameter lines and the way in which they are assigned to specific telecommunications unit numbers in the JCL. </p>
<var class="product">Model&nbsp;204</var> terminal security allows access to certain login user IDs, files, or groups to be restricted to users at certain terminals. For example, you might want a particular MEDICAL file to be accessible only through terminals located physically in doctors' offices.    </p>
<p>The batch user (User 0) is considered to be terminal 0 (zero). A user at a particular terminal whose number is n can log in to a specific user ID or open a specific file or group only if the terminal number, n, is in the terminal list associated with the password for that user ID, file, or group. If it is not, <var class="product">Model&nbsp;204</var> responds as though the user had entered an invalid password.</p>
<p>
<p>Terminal security is generally used with only hard-wired terminals, that is, terminals on leased lines. If an installation has dialup terminals, the terminal can be connected to a number of similar telecommunications units and user parameter lines. In this case, although the location of the terminal can be fixed, its terminal number can change evep>The entries in the ACT do not take effect for users that have the file open when the SECURE command is issued until they reopen the file. This includes the user who issues the command. The complete syntax and description of the SECURE command is located in the ry time it is dialed up.</p>
The terminal security feature allows a list of terminal numbers to be associated with each login, file, or group password. A terminal number is determined during <var class="product">Model&nbsp;204</var> initialization by the order of the user parameter lines and the way in which they are assigned to specific telecommunications unit numbers in the JCL. </p>
<p>By controlling the assignment of terminal numbers to physical terminals, the system manager determines the appropriate terminal security scheme. You provide assistance in limiting file and group access through file passwords and privileges, and group passwords and privileges.</p>
<p>
<p>&nbsp;</p>
The batch user (User 0) is considered to be terminal 0 (zero). A user at a particular terminal whose number is n can log in to a specific user ID or open a specific file or group only if the terminal number, n, is in the terminal list associated with the password for that user ID, file, or group. If it is not, <var class="product">Model&nbsp;204</var> responds as though the user had entered an invalid password.</p>
<p>
Terminal security is generally used with only hard-wired terminals, that is, terminals on leased lines. If an installation has dialup terminals, the terminal can be connected to a number of similar telecommunications units and user parameter lines. In this case, although the location of the terminal can be fixed, its terminal number can change every time it is dialed up. </p>
<p>
The entries in the ACT do not take effect for users that have the file open when the SECURE command is issued until they reopen the file. This includes the user who issues the command. The complete syntax and description of the SECURE command is located in the ry time it is dialed up.</p>
<p>
By controlling the assignment of terminal numbers to physical terminals, the system manager determines the appropriate terminal security scheme. You provide assistance in limiting file and group access through file passwords and privileges, and group passwords and privileges.</p>
</div> <!-- end of toclimit div -->


[[Category:File management]]
[[Category:Model 204 files]]

Latest revision as of 19:20, 17 November 2023

Overview

A variety of security features provide Model 204 users with protection against unauthorized use of their account names, files, groups, records, fields, procedures, and terminals. This section describes the role of the file manager in maintaining Model 204 security.

Additional documentation on security features

Using the Model 204 password table

The Model 204 password table is the backbone to the security features in Model 204. The user must enter a valid password to access the Model 204 Online, files, groups of files, and subsystems, which in turn affects access to records. The security feature in Model 204 is not based on a hierarchy, but rather on direct password validation.

The password table, CCASTAT, is set up by the system manager. When the file manager determines which users or groups of users can have access to what data, then the file manager works with the system manager to correctly set up the password table and file access.

Types of security

All Model 204 security features are optional. A site can support any combination of features. The file manager is primarily responsible for file, group, record, field, and procedure security. Both system and file managers handle terminal security. The file manager's responsibilities are described in this topic.

Type of security Function
Login (System manager) Limits access to the Model 204 system by requiring an individual user to enter a password when logging in. Only users who enter a valid password can gain access to the system. When a user successfully logs in, specified privileges are granted.

See Login security and the LOGCTL command for modifying user ID entries.

File (File manager) Protects certain types of files by requiring a user to specify a valid file password in the OPEN command or OPEN statement. After successfully opening a file, a user is granted particular privileges pertaining to the data and procedures in that file, as well as a user class number for procedure security, and field-level security access levels.
Group (File manager) Protects certain types of file groups by requiring a user to specify a valid group password in the OPEN command or OPEN statement. When a user successfully opens a permanent group, the user is granted specified privileges that pertain to the files in the group. When opening a temporary group, the user is granted the privileges that all the member files have in common.
Record (File manager) Limits access to particular records in a Model 204 file. When record security is in effect, a user can retrieve and update only those records stored by the user's login ID or records that other users have agreed to share.
Field-level (File manager) Protects sensitive fields in a Model 204 file. Field-level security levels are granted when opening a file or group, and they indicate the type of access (for example, READ, UPDATE) to the field that the user is allowed.
Procedure (File manager) Limits access to the procedures in a file. It indicates whether a user is authorized to access particular procedures and specifies the type of access (for example, DEFINE, DELETE) that the user is allowed in secured procedures.
Subsystem (System manager) Controls the privileges that are assigned to users who enter a subsystem. The system manager assigns users subsystem command privileges and privileges for each file and group in the subsystem.
Terminal (File and system managers) Allows specified login user IDs and specified files and file groups to be accessed only from certain hard-wired terminals.

Multi-factor Authentication - MFA

Support for logon with Multi-factor authentication (MFA) is also provided with no updates or parameter changes required to Model 204. MFA does require that one of the three security interfaces, listed below, be linked into the Model 204 nucleus. Once a userid is provisioned under MFA, the user acquires a token from a client, e.g. IBM Security Verify, installed on the user's mobile device. That token is then concatenated, with a password or passphrase, to logon to Model 204. For example: token:password or token:passphrase, where colon (:) is the concatenating character. That string is passed, unmodified, to the security interface for verification.

  • ACF2
  • RACF
  • TopSecret

File security

Model 204 file security features allow you to restrict access to particular files to designated users, as well as to limit the operations that can be performed on those files. Although you are primarily responsible for determining the file security scheme in a Model 204 system, you can allow users to change a password for a file if you provide them with the appropriate login privileges.

Security for files opened in a subsystem operates differently. See Subsystem security for more information.

File manager's responsibilities

Ordinarily, the file manager determines which files and file parameters to protect from unauthorized access and determines the initial passwords and associated privileges for the files. It is then the system manager's responsibility to add entries for these files to the password table. The password table contains password and privilege information for files, file groups, and login user IDs. Maintaining this table is discussed in Password table data set.

Defining access levels for files

The file manager is responsible for defining the default access levels for public and semipublic Model 204 files. You are also responsible for determining the four access levels that belong with each file or group password. These levels are then added by the system manager.

File privileges

File privileges determine the type of operations that the user is authorized to perform on the file that is being opened. The types of files are:

If the file is... Then Model 204...
Public Opens the file without asking for a file password and grants the user default file privileges as specified by the PRIVDEF parameter.
Semipublic Prompts the user to enter a valid password:
  • If the user enters a valid password, the user is given the privileges associated with that password.
  • If the user does not know the password or enters an incorrect password, the file is still opened but the user is granted the default file privileges associated with the file.
Private Prompts the user to enter a valid password:
  • If the user enters a valid password, the file is opened and the user is granted the privileges associated with that password.
  • If the user does not know the password or enters an invalid password, the file is not opened.

OPEN command and OPEN statement

For a discussion of the OPEN command and the way in which a user specifies a password when opening different types of files, refer to OPEN FILE command and also see OPEN statement and OPENC statement.

Creating files with file security

When a file is first created with the CREATE command, you can limit access to the file by setting two system parameters, OPENCTL and PRIVDEF, and by asking the system manager to enter one or more file passwords in the password table. Also, the OPENCTL and PRIVDEF parameters can be reset at a later time.

The following sections provide a further description of file passwords and privileges, as well as the OPENCTL and PRIVDEF parameters.

File passwords and privileges

You can define several passwords for a file. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the file by the user who opens the file with that password.

If you do not specify values for OPENCTL and PRIVDEF when you create the file, the file is assumed to be a public file that has a full set of default file privileges. This implies that any user can open the file using the OPEN command or OPEN statement without having to enter a file password, and can then retrieve and update data, define and run procedures, or access file parameters.

Creating passwords

Passwords can be up to eight characters long and cannot contain blanks, commas, or colons.

OPENCTL parameter

The OPENCTL parameter determines whether or not a user must enter a file password when opening the file. Except as specified in the following table, OPENCTL settings can be added together. The first three settings are mutually exclusive and one of them must be included in your OPENCTL specification. The remaining settings in the table are options that you can add to one of the first three settings.

Setting Means file is... Password handling
X'80' Public

Password is not requested and the file is opened with default privileges.

This setting cannot be combined with X'40'.

X'40' Semipublic

User is asked for a password. For a valid password, the user is given the associated privileges. Otherwise, the user is granted default file privileges.

This setting cannot be combined with X'80'.

X'00' Private Without a valid password the file is not opened.
X'20' Using record security

No effect.

The user must have a security level that permits some type of access.

Additional options for Parallel Query Option (PQO)
X'08' Accessible remotely without a valid password

For a public file, no password is requested and the file is opened with default privileges.

For a semipublic file, a password is requested. If the password is missing or invalid, the user is granted default file privileges.

For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened if X'02' is set.

X'04' Accessible remotely as a permanent group member Model 204 permanent group security is in effect. Password handling for local users is unaffected.
X'02' Accessible remotely with a valid password For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened.
X'00' Accessible remotely through APSY For any file, no password is requested and the file cannot be opened remotely, except within a trusted subsystem.

For PQO sites, the OPENCTL parameter determines how a file can be accessed remotely. The PQO remote access settings have no meaning for local files. For more information about PQO remote files, see PQO: Remote files and scattered groups.

PRIVDEF parameter and file privileges

The PRIVDEF parameter summarizes the default file privileges that are assigned when a public file is opened, or when a semipublic file is opened without a password or with an invalid password. Privileges can be set to any combination of the following bit settings. These privileges are identical to the privileges that can be specified for an individual file password in the password table.

Bit User can...
X'8000' Issue file manager privileged commands such as INITIALIZE, SECURE, and DESECURE. The file manager can also reset file parameters, provided that ad hoc update privileges (X'2000') are obtained.
X'4000' Override record security; see Record security.
X'2000' Update data with ad hoc requests or host language programs.
X'1000' Make changes to internal procedures, that is, procedures defined in the same file as the data, but cannot delete them.
X'0800' Update data using internal procedures.
X'0400' Retrieve data with ad hoc requests or host language programs.
X'0200' Display, echo, and copy internal procedures.
X'0100' Retrieve data with internal procedures.
X'0080' Update data using external procedures, that is, procedures defined in a different file from the data.
X'0040' Retrieve data using external procedures.
X'0020' Include internal procedures.
X'0010' Define internal procedures.
X'0008' Delete internal procedures.
X'0001' Access file related parameters. The affected parameters are described in Setting file parameters.

PRIVDEF default setting

The default value for the PRIVDEF parameter is X'BFFF', that is, all privileges except the ability to override record security.

Combining PRIVDEF settings

Update privileges, for example, update using ad hoc requests, do not imply corresponding retrieval privileges. Thus, a user who has only the ability to update using ad hoc requests (X'2000' bit set) cannot find any records to update. A user must be given both update and retrieval privileges (X'2400') to update data effectively.

Similarly, privileges for data retrieval using internal procedures (X'0100') do not imply that the user can include a procedure from the file. The X'0020' privilege is required for this.

If procedure security is desired, you must relate procedure class numbers to the procedures stored in the file. Also, determine the field-level security levels for any fields in the file that are particularly sensitive and need to be protected against unauthorized access. Field and procedure security features are discussed in Field-level security and Procedure security.

Resetting PRIVDEF or OPENCTL

When the OPENCTL parameter is reset to X'80' (public), the assigned privileges are those of the current value of the PRIVDEF parameter. This means that if OPENCTL is reset to X'80' while PRIVDEF is set to less than full file manager privileges, you cannot update the file or reset any file parameters. This can also occur if you reset PRIVDEF while OPENCTL is set to X'80'.

To avoid this problem, use the VIEW PRIVDEF command to ensure that you have appropriate PRIVDEF privileges before you reset OPENCTL to X'80'. Be very careful about resetting PRIVDEF for a public file.

Regaining access

If you do accidently lock yourself out of a file, you can regain access as follows:

  1. Have the system manager create a permanent private group that contains the locked file.
  2. Have the system manager add a group password (and tell you that password) to the password table, CCASTAT, with the privileges X'BFFF'.
  3. Then, open the private group and issue one of the following commands:

    IN FILE name RESET OPENCTL=X'40'

    or:

    IN FILE name RESET PRIVDEF=X'BFFF'

    where name is the name of the locked file.

Securing and desecuring a file

Making files secure

Securing a file ensures that a user cannot access a file illegally by running a Model 204 program with a different password table. A special key in the password table serves as the key for securing a file. The key can be changed by the system manager with the LOGKEY command. When a secured file is opened, Model 204 compares the key to a copy placed in the file by the SECURE command. The file is opened if the two fields match. If the fields do not match, the user is logged out and an error message is displayed on the operator's console.

The SECURE command, which can be issued only by a file manager, provides additional file protection by securing the currently open file. This form of the command is issued without arguments:

SECURE

Desecuring a file

To desecure a previously secured file, issue the command:

DESECURE

For a description of using the SECURE and DESECURE commands with procedures, refer to Procedure security.

Group security

The Model 204 group security features allow access to particular file groups to be limited to certain users.The file manager is primarily responsible for group security and for the file security features discussed in the preceding section.

Group passwords

Ordinarily, the file manager determines which groups to protect from unauthorized access, and indicates the passwords and associated privileges for these groups. It is then the system manager's responsibility to add entries for these groups to the password table and recommend group parameter settings. The system manager, however, is the only user authorized to create permanent groups. This is done with the CREATE command, as described in Creating file groups.

Opening permanent file groups

If passwords are required for a permanent file group, only users who know one of the group passwords can open the group. As with file security, the group password determines the types of operations that the user is authorized to perform on the group that is being opened. The privileges associated with the password determine the extent of these operations. Group security operates differently under the Subsystem Management facility. See Subsystem security.

Opening temporary file groups

Opening a temporary group is functionally equivalent to opening a series of files. Only the user who creates a temporary group can open it. To open a temporary group, the user must be able to open each file in the group individually.

Group file privileges

The types of permanent groups are:

  • Public
  • Semipublic
  • Private

These types are the same as described in File manager's responsibilities.

When a user opens a semipublic or private group, Model 204 requests that the user enter the password. When the group is opened, the user is granted either the privileges associated with the group password or the default privileges for the group, depending on the password supplied. Default privileges are also supplied when a public group is opened.

Group passwords and privileges

A permanent group can have several passwords defined for it. Like a file password, a group password can have up to eight characters and cannot contain blanks, commas, or colons. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the group by the user who opens the group with that password. Privileges are expressed as two hexadecimal bytes, as discussed in PRIVDEF parameter and group privileges.

PRIVDEF parameter and group privileges

If a value for PRIVDEF and a PUBLIC, SEMIPUB, or PRIVATE specification is not specified at the time that the group is created, the group is assumed to be a PUBLIC group that has default privileges of X'3FFF'. The PRIVDEF parameter, which summarizes the default privileges for a group, provides all the privileges shown for files, plus the two group privileges summarized here. These privileges are identical to the privileges that can be specified for an individual group password in the password table. The X'8000' privilege has no meaning for groups, although it can be important for individual references to member files.

Bit User can...
X'0004' Update data through procedures from the procedure file.
X'0002' Retrieve data through procedures from the procedure file.

When a group is created, one of its member files can be designated as the procedure file. This is the file in which procedures for the group are stored and from which procedures are retrieved or deleted.

In a group context, internal means that a file is a member of the group, while external means that a file is not a member of the group.

Determining file and group privileges

When a command or a SOUL statement refers to a file or group, Model 204 checks the file and group privileges to ensure that the operation is allowed. Model 204 must determine whether a file has been opened as an individual file, as a member of a permanent or temporary group, or as both.

The privileges associated with individual files and groups can be granted and combined in different ways, depending upon the reference context, as shown in the following table.

Referring to... User's privileges are...
Individual file Same as those granted by Model 204 when the file was opened. These privileges are associated with the specified file password or, if no password is required or is incorrectly specified, the default file privileges.
Temporary or ad hoc group Intersection of the individual privileges associated with the files that make up the group. Model 204 compares the privileges of all of the member files; only privileges that are common to every file are granted.
Permanent group Same as those granted by Model 204 when the group is opened. These are the privileges associated with the specified group password or, if no password is required or is incorrectly specified, the default group privileges.
Member of a permanent group
(not opened individually)
Those granted for the group.

If the file is opened individually, its privileges remain those granted when the file was individually opened.

Two permanent groups
(not opened as individual files)
Union of the privileges associated with the groups. Model 204 combines the privileges of all open groups of which the file is a member. Any privileges specified for any of the groups are granted.
File open as both an individual and a group Privileges associated with the file, not the group. No open group has an effect on the file privileges.

Record security

In addition to protecting an entire file or group from unauthorized access, you can also protect individual records in a file. When record security is in effect for a particular Model 204 file, each user can be allowed to retrieve and update only records stored in the file with that user's ID or records that other users have agreed to share. The user does not know that any other records exist.

Record security can be in effect for one or more of the files in a group, but not for the group as a whole. Access to a single record depends on only the record security field defined for the record's file.

Record security and login security

Model 204 record security can be considered as an extension to login security and cannot be used unless the login security feature is in effect at an installation. Login security is primarily the system manager's responsibility, and it is discussed in detail in Login security.

File manager responsibilities

Record security usually is the responsibility of the file manager. To initiate record security, set the OPENCTL parameter in the CREATE command to indicate that record security is in effect and describe the special record security field in the INITIALIZE command, which is discussed in Initializing record security files. You can turn off record security by using the appropriate OPENCTL setting with the RESET command, but it cannot be turned on by RESET. The file must be defined to have record security through the CREATE command.

Setting record security for remote users

If your site has the Parallel Query Option/204 product, you can control access to remote files with record security using the PQOSYS CCAIN system parameter. If set, PQOSYS creates a special record security key for remote users. For more information about PQOSYS, see Record security for remote users: the PQOSYS parameter.

Storing and retrieving records

After a file has been initialized with a record security key, each record stored in the file with a SOUL STORE RECORD statement automatically has a record security field added to it, whose value is equal to the current user's login user ID.

Storing record security fields through File Load or the Host Language Interface

For records stored with a Host Language Interface IFBREC or IFSTOR function or by a file load program, a record security field must be added explicitly, along with other fields, when the record is created. For example, the following file load statement adds a record security field:

LDC RECSEC=DARCY=

Refer to File Load utility for information about the File Load utility.

Only records that have a record security field whose value is equal to the current user's login user ID are retrieved by a SOUL FIND statement or Host Language Interface calls that perform a find function. If the FILE LOAD statement shown here is executed, for example, only a user logged in under the name DARCY can retrieve these records.

Allowing multiple access

To share a record with another user, either you or the user can add an explicit occurrence of the record security field with a value equal to the second user's login user ID. If the second user has update privileges, that user can delete the first value of the record security field, thus making the record accessible only through the second user's user ID.

Multiple access in 1NF files

To allow access to record security fields in 1NF files, you must define the record security field as INVISIBLE and REPEATABLE.

Overriding record security

Occasionally, it may be necessary to override the Model 204 record security scheme. To override record security, you must have the appropriate record security override privileges at login time: the X'04' bit must be set. When the file is opened, the X'4000' bit must be set.

If both privileges have been granted, you can retrieve all records, regardless of the record security key value associated with them. However, if you store records from User Language at this time, they still have the record security field with the value of your login ID added to them automatically.

If record security was specified for a file in a permanent group, you can override record security for the file if login and group privileges (X'4000') allow it.

For further information regarding login security bit settings, see File security.

Field-level security

Field-level security (FLS) provides an additional level of protection for a user's data by controlling access to the individual fields of a Model 204 file. It involves a comparison of the user's predetermined numeric access level for a field with the field's own predetermined level, for each of four types of access. Field-level security specifications are put into effect only if access to a data record has been allowed by previous file-level and record-level security checks. The following paragraphs describe in detail how field-level security operates.

In addition to field-level access for each field, each file has a default access level (that is, all fields within the file are automatically assigned access levels).

The following parameters determine the default field access:

This parameter Provides this default field access...
SELLVL SELECT
READLVL READ
UPDTLVL UPDATE
ADDLVL ADD

Like PRIVDEF, these parameters can be set when a file is created, or they can be reset later. If not explicitly specified, all of these parameters are set to zero, which allows a user to access only unsecured fields (that is, fields with access levels of 0). The same four parameters can be set for a permanent group when it is created by the system manager.

File manager responsibilities

The file manager is responsible for determining the desired field-level security scheme and for assigning security levels to fields that are to be protected. The LEVEL option allows you to indicate the security level for the field.

For example, if the following command is issued, only users who have access levels of 70 or greater are allowed to access the PERFORM field, which might contain an employee's performance evaluation code:

DEFINE FIELD PERFORM WITH LEVEL 70

Types of field access

By using the Model 204 field-level security scheme, you can protect particularly sensitive data fields from unauthorized access. A field can be accessed in several different ways.

Field-level security features limits access to a field to any combination of the following access types:

This access type Allows you to...
SELECT Use the field in a SOUL FIND statement or in an IFFIND call.
READ Examine the value of a field, for example, in a SOUL PRINT or assignment statement or an IFGET call.
UPDATE Change the value of a previously stored occurrence of a field. This type of access can be granted without a corresponding READ access, which precludes updates of the form shown below:

CHANGE fieldname = value TO value

ADD Add new occurrences of a field, including those added by a STORE RECORD statement. This type of access allows data entry clerks or other personnel to add new field occurrences or records without being able to change existing occurrences, or possibly even to examine them.

This type of access can also provide a user with the ability to add occurrences of the record security field without altering existing occurrences.

Field-level security controls only explicit field references. Implicit references, such as retrieving a record security field with a FIND statement or adding a record security key value with STORE RECORD, are not controlled.

Field levels

Every field definition can have a security level associated with it. Security levels are numbered from 0 to 255. 0 implies no security for the field; 255 implies the highest security.

Field-level security and field ordering

In the Model 204 field-level security scheme, fields can be assigned security levels in a hierarchical fashion. The fields can be ordered in view of the sensitivity of the data that they contain. An example of such an ordering is shown in Field levels, the fields being listed in order of increasing sensitivity.

Field-level ordering example
Field FLS READ level
Last name 0
First name 0
Employee number 0
City 10
State 10
Zip code 10
Street address 20
Position 30
Telephone number 40
Salary 60
Performance evaluation 70

In Field levels, performance evaluation is considered to be the most sensitive field in the record, followed by salary, and so on. Last name, first name, and employee number have not been assigned field-level security numbers. However, file, record, and procedure security features still can be used to control access to those fields.

User levels

Each user has four field-level security access levels associated with each file and group opened. These correspond to the four field access levels defined previously: SELECT, READ, UPDATE, and ADD. User levels also range from 0 to 255.

When a user attempts to access a field in a particular way, Model 204 compares the user's access level with the level assigned for the field. If the user's level for the desired type of access, for example, READ, is greater than or equal to the field's FLS level, the particular type of field access is allowed.

User-level security example

For example, a user who has a READ level of 30 is permitted to print any field that has a READ level between 0 and 30, but cannot print a field that has a higher READ level. Thus, when using the file described above, a user who has a READ level of 30 can print an employee's position (and all fields that have lower FLS fields), but not the employee's telephone number, salary, or performance evaluation. An example of a possible set of access levels at an installation is shown below:

User access levels example
Employee category SELECT READ UPDATE ADD
Data entry clerks 0 0 0 60
Personnel department clerks 50 50 40 0
Personnel department supervisor 70 70 70 0
Other employees (for example, telephone operators) 0 10 0 0
Employee supervisor 0 70 0 70

The motivations for these assignments easily can be understood in relation to the sample file. Only data entry clerks can add employee records; only supervisors can add performance evaluations; only personnel department supervisors can update salaries, and so on.

Referring to or displaying fields

When a user's access levels are lower than permitted for the level of a particular field, a reference to the field is treated as a reference to a nonexistent field. Furthermore, the names of such fields are excluded from the output of the DISPLAY FIELD ALL command. Thus, when using the file shown in User levels, only personnel and employee supervisors know that a performance evaluation field even exists in the file. The field is never visible to other users.

Limiting access to fields

Access to records for particular employees can be controlled in another way. Employee supervisors usually are given a password that allows them to read or add any field in the file. However, procedure- or record-level security can be used to restrict supervisors' access to only the records of their employees.

Determining user access levels

The access levels assigned for a user are determined when the user opens a file or a group using the OPEN FILE command, OPEN PERM GROUP command, or OPEN TEMP GROUP command or using the OPEN statement. Access level assignments are made for various types of files or groups as follows:

  • If a file or a permanent group is public or semipublic and an incorrect password is specified in the OPEN, the user's four access levels are taken from the file or group defaults described in Procedure security.
  • If a private or semipublic file or group is opened with a valid password, the user's four access levels are the same as those associated with the password.
  • If a temporary or ad hoc group is opened, all the member files are opened separately as individual files. Opening these individual files establishes a set of four access levels for each member file.

Access levels for temporary or ad hoc groups

The four access levels for a temporary or ad hoc group are formed by taking the minimum of each access level across all the member files. Suppose that FILEA and FILEB have the access levels shown in the following table.

File SELECT READ UPDATE ADD
FILEA 30 40 10 0
FILEB 40 30 0 10

If a temporary group named FILES, consisting of FILEA and FILEB, is opened, the group is assigned the access levels:

Group SELECT READ UPDATE ADD
FILES 30 30 0 0

This is equivalent to the comparison of file privileges that occurs when opening a temporary or ad hoc group; see Group security.

Examples

The following examples show how your user access levels for a file can change as the reference context changes. In the examples, the four user-access levels, SELECT, READ, UPDATE, and ADD, are represented by their first letters.

A field reference occurs in single file context, and the file is opened as a single file:

S R U A OPEN FILE FILEA 100 100 10 20 BEGIN FPC NAME=JONES END

The four access levels used in checking field references (100, 100, 10, 20) are those assigned when FILEA was opened as a single file.

A field reference occurs in group context:

S R U A OPEN FILE GROUPA 50 75 20 0 BEGIN FPC NAME=JONES END

The four access levels used for checking field references in any file of the group (50, 75, 20, 0) are the four assigned when the group was opened. All the files in a group receive the same four access levels.

A field reference occurs in single file context, but the file was opened only as a member of one or more permanent groups. FILEA is a member of the two groups, GROUPA and GROUPB:

S R U A CLOSE FILE FILEA OPEN GROUP GROUPA 50 75 20 0 OPEN GROUP GROUPB 50 50 0 100 BEGIN IN FILEA FPC NAME=JONES END

The four access levels used in checking field references (50, 75, 20, 100) are formed by taking the maximum level defined for the file by every group containing the file that the user has opened.

Procedure security

Model 204 procedure security limits access to a file's procedures in the following ways:

  • By allowing you to specify user privileges that control the type of functions that can be performed on the procedures within a file, for example, to display, define, or delete the procedure.
  • By limiting access to a procedure to only a particular class of users. This is done by assigning a procedure class number to the procedure that is being secured and a user class to the users allowed to manipulate the procedures.

These security features are discussed in greater detail in the following sections. In addition, File security and Group security discuss the privileges that enable users to access the data in a file or group through procedures.

Accessing procedures

At the time a file or group is opened, particular privileges are established that concern the text of the procedures stored in the file or group. These privileges, or access rights, enable a user to manipulate a procedure in any of the following ways:

  • Use the procedure, for example, by specifying it in an INCLUDE command.
  • Display and copy the procedure. This includes echoing the procedure and using the EDIT command to display or copy it.
  • Change the procedure, usually with the Editor.
  • Define a new procedure in the file with the PROCEDURE command or the Editor.
  • Delete a procedure by means of the DELETE command.

For information about the basic procedure functions, see the $Prc* and $Proc* functions in List of $functions; and for information about procedure related commands, see Category:Commands.

Securing procedures

The privileges established for procedure access discussed in PRIVDEF parameter and file privileges are used to limit the way in which the procedures associated with a file or group can be accessed. Model 204 provides an additional facility that allows particular procedures to be secured and thus protected from unauthorized access.

User and procedure classes

You can limit user access to procedures by assigning user classes that have access to procedures in a particular procedure class.

User and procedure classes are usually put in place as part of the security scheme for a file or group. Although every user and procedure could have a distinct class number (UCLASS and PCLASS), this approach is too complex and cumbersome for most installations. Thus, sets of procedures and users more often are handled together.

User classes (UCLASS)

Examples of typical user classes are:

  • All employees in a department
  • All managers, regardless of department
  • All data entry personnel

Procedure classes (PCLASS)

Examples of typical procedure classes include procedures that:

  • Display salary data
  • Update personnel records
  • Perform general utility operations
  • Access sensitive fields in files

Procedure classes and user classes are arbitrary numbers that range from 1 to 255. Their only significance is in their relationship to each other. The numbers are assigned as described in User and procedure classes.

When a user opens a file or group, the user is given the privileges and user class determined by the OPEN:

  • If the file or group is opened with a password, the user class is obtained from the password table, where it is stored with the privilege bytes and field-level security levels for the password.

    The user class normally is provided by the file manager and entered into the password table by the system manager, as discussed in Password table maintenance.

  • If the file or group is opened without a password, the user is granted default privileges and a default user class. This default user class is the value of the PRCLDEF system parameter, which has a default value of zero and can be set by the file manager.

Relationship between user and procedure classes

An access control table (ACT) stored in each file assigns to particular user classes the access rights to particular procedure classes. These mappings from user class to procedure class in the ACT are created using the SECURE command described in SECURE command, definition format.

The user class established for a group applies to all its member files. If a file is opened only as part of a permanent group, any reference to a secured procedure compares the user class specified for the group against the procedure's class to determine the available access rights.

Example

The association of user classes and procedure classes can be explained best by an example:

Suppose that a user whose user class is 8 includes a procedure named CENTEST, which has a procedure class of 20. Model 204 must determine whether users of class 8 are allowed to include procedures of class 20.

If Model 204 checks the ACT in the file in which CENTEST is defined and finds that an INCLUDE is permitted, the procedure is included. If, however, INCLUDE is not permitted for users of class 8, the INCLUDE does not take place and an error message is issued.

This mapping of user and procedure classes is discussed in greater detail in the sections that follow.

Assigning procedure classes

A procedure class can be specified for a procedure by the file manager or by an individual user. The class can be assigned:

  • By the user when defining the procedure with the PROCEDURE command
  • By the file manager when securing the procedure with the SECURE command
User-defined procedure classes

When defining a procedure, the user can specify a procedure class number in the following format:

PROCEDURE name PCLASS=n

Where:

n is any number in the range 1 through 255.

A user's access rights to procedures are checked first at the file level and then at the procedure level. Thus, if the user is to be allowed to change a secured procedure, the user must have procedure update file privileges, and the appropriate entry must have been made in the ACT.

File manager-defined procedure classes

File manager-defined procedure classes are discussed in the following sections, in context of the commands that the file manager uses for this purpose.

SECURE command, definition format

If you have appropriate file manager privileges, you can use the SECURE command in the following form to:

  • Secure both files and procedures
  • Define privileges for procedures that already have been secured
  • Make entries in the access control table

The format is:

SECURE [PROCEDURE] NAME=procname [,procname ...] PCLASS=pclass

Where:

  • procname is the name of an existing procedure to be secured.
  • pclass is the procedure class number to assign to the procedure(s); the number must be in the range 1 to 255.
  • The SECURE command must be issued in file context, that is, the current default must be a file, not a group.

Example

The following example is a SECURE command used to secure a procedure:

SECURE PROCEDURE NAME = PAY PCLASS = 7

After this command is issued, the procedure PAY is secured with the procedure class number 7. An entry for PCLASS=7 is made in the procedure dictionary. If PAY is currently secured, its old procedure class is changed to the new class.

SECURE command, mapping format

The SECURE command lets you map particular access privileges and user classes to particular procedure classes. This command creates entries in the access control table. Issue the following form of the command:

SECURE [PROCEDURE] ACCESS = {ALL | (access [,access...]) | NONE} UCLASS = {ALL | (uclass [,uclass...])} PCLASS = {ALL | (pclass [,pclass...])}

Where:

  • access is a particular privilege associated with the procedures in the procedure class. It can be one of the following:
    Privilege Users can...
    USE Include procedures.
    COPY Display and edit (copy only) procedures.
    CHANGE Edit procedures.
    DEFINE Create new procedures (PROCEDURE and EDIT).
    DELETE Delete procedures.
  • uclass is the user class number whose users have access to the procedures in PCLASS; the number must be in the range 1 to 255. Parentheses are optional in the uclass definition.
  • pclass is the procedure class number to which users in UCLASS have access; the number must be in the range 1 to 255. Parentheses are optional in the pclass definition.

Example

In the following example, only users in the Payroll Department (user class 90) are allowed to use procedures that manipulate salary fields in a file (procedure class 20 and 30):

SECURE PROC ACCESS = (USE) UCLASS = 90 PCLASS = 20,30

The entries in the ACT do not take effect for users that have the file open when the SECURE command is issued until they reopen the file. This includes the user who issues the command. See SECURE PROCEDURE ACCESS command for the complete syntax and description of the SECURE command.

To complete procedure security implementation, the system manager updates the password table using the LOGCTL command to assign user classes to the appropriate passwords.

Procedure-related commands and required privileges

The following list is a summary of Model 204 procedure or procedure-related commands that require particular privileges. All these commands are described in the Model 204 Parameter and Command Reference.

Privileges for procedure or procedure-related commands
Command Required privileges
INCLUDE USE  
EDIT COPY  
DISPLAY COPY (to display text)  
DELETE DELETE  
ASSIGN CHANGE  
DEASSIGN CHANGE  
RENAME CHANGE  
Command New procedure Old procedure
PROCEDURE DEFINE CHANGE
EDIT commands:

GO
END

DEFINE, USE* DEFINE CHANGE, USE* CHANGE
*COPY privileges are required in addition to USE to echo text lines of a procedure to a journal.

Displaying user and procedure classes

The SECURE command constructs entries in the access control table for any user classes specified in the UCLASS clause.

Note: It is important to display procedure security and save it before reorganizing a file, so that you can reestablish the same security. You might have to upgrade your file manager privileges to include COPY, which is not part of the default privileges of a file manager.

To determine a user's access rights for various procedure classes, issue the following form of the DISPLAY command:

DISPLAY [PROCEDURE (PRIVILEGES [,NOUSE]) [ALL | UCLASS = uclass[,uclass...]]

Where:

  • ALL displays information for all user classes.
  • uclass displays information only for the specified classes.
  • If neither is specified, your current class and privileges are displayed.

    Privileges are displayed in the following format:

    UCLASS=u PCLASS=pc,X'nn' . . . PCLASS=pc,X'nn'

    Where:

    • u is the user class.
    • pc is a procedure class defined for that user class.
    • nn is a privilege byte constructed from combinations of the following bit settings:
      Bit Privilege
      X'80' USE
      X'40' COPY
      X'20' CHANGE
      X'10' DEFINE
      X'08' DELETE
  • If NOUSE is specified, information is displayed at your terminal even if a USE command preceded the DISPLAY command. The device specified by the USE command is not used but is left open.

See the discussion of other DISPLAY command capabilities in Overview.

Sample security scheme

A simplified example of a security scheme at an installation is presented in this section. At this installation, the following access rules are established:

  • Most users are allowed to include all secured procedures.
  • Only programmers in the data processing department are allowed to define procedures. However, they cannot use them. These programmers can have user classes 8 or 9.
  • Only users in the payroll department are allowed to use procedures that manipulate salary fields in the file. Payroll users are assigned class 90, and the payroll procedures are in procedure classes 20 and 30.
  • Other users are assigned user classes 25, 30, or 31.
  • Other procedures are in procedure classes 40, 50, 60, or 70.

Sample SECURE commands

To create the security scheme in this example, issue the following commands:

SECURE PROC ACCESS=(CHANGE,DEFINE,DELETE,COPY) UCLASS=8,9 PCLASS=20,30,40,50,60,70 SECURE PROC ACCESS=(USE) UCLASS=90 PCLASS=20,30 SECURE PROC ACCESS=(USE) UCLASS=25,30,31,90 - PCLASS=40,50,60,70

Importance of SECURE command order

In this example, the order of the SECURE commands is unimportant. However, the order becomes significant when a UCLASS=ALL or PCLASS=ALL clause is included in the command. UCLASS=ALL affects only user classes already mentioned in the ACT. This might be completely different from the list of user classes that actually can be assigned to users from the password table or default file or group settings.

When PCLASS=ALL is included in the command, no new entries are added to the ACT. Instead, for each user class in the UCLASS list, access rights for each procedure class already mentioned for that user are replaced by the new ACCESS rights. Again, the classes affected in the ACT may be completely different from those actually used for secured procedures in the file.

Changing and adding access privileges

Suppose, in this sample security, that the payroll users now need to be able to display all the procedures that they use. Also, suppose that a new set of procedures (of class 15) is developed that all users (including the programmers) can include. The following commands are issued in the order shown to modify the ACT entries already built:

SECURE PROC ACCESS=(USE) UCLASS=ALL PCLASS=15 SECURE PROC ACCESS=(USE,COPY) UCLASS=90 PCLASS=ALL

If these commands are reversed, the payroll users cannot display members of the new class of procedures.

Removing procedure security for procedures or user classes

To remove the procedure access defined for user class/procedure class pairs, use the DESECURE command:

  1. Remove the security for the procedure involved.
  2. Delete the procedure class number assigned to the procedure in the procedure dictionary by issuing the form of the DESECURE command immediately below.

Note: If you do not do this, no one can access the procedure, even though the entry might have been removed from the ACT (see the second form of DESECURE below).

Only file managers can issue the DESECURE command and it must be issued in file context (that is, the current default must be a file, not a group).

The format of the DESECURE command is:

DESECURE PROCEDURE {ALL | NAME=(procname[,procname...])}

Where:

procname is the name of an existing secured procedure.

To remove particular access privileges for particular procedure classes, use the following form of the DESECURE command to delete entries from the ACT. You must specify either UCLASS or PCLASS, or both.

The format is:

DESECURE PROCEDURE {[UCLASS= {ALL | (uclass[,uclass...])}] | [PCLASS= {ALL | (pclass[,pclass...])}]}

Where:

  • uclass is the number of an existing user class whose users have access to the procedure in pclass; the number must be in the range 1-255. If only UCLASS is specified, all references to the specified user classes are removed from the ACT.

    Parentheses are optional with uclass.

  • pclass is the number of an existing procedure class to which users in uclass have access; the number must be in the range 1-255. If only pclass is specified, all references to the specified procedure classes are removed from the ACT.

    Parentheses are optional with pclass.

Desecuring both UCLASS and PCLASS

If both UCLASS and PCLASS are specified, the entries for all combinations of the specified user and procedure class pairs are removed from the ACT. For example:

DESECURE PROC UCLASS=8,9 PCLASS=1,2,3

removes access entries for:

UCLASS 8 and PCLASS 1 UCLASS 8 and PCLASS 2 UCLASS 8 and PCLASS 3 UCLASS 9 and PCLASS 1 UCLASS 9 and PCLASS 2 UCLASS 9 and PCLASS 3

System manager responsibilities

The final step in the desecuring process is to have the system manager remove the password(s) with associated uclasses from the password table. If they are not removed, you must remember not to use them when opening the file.

Privileges required

You must have file-level privileges of at least X'A000' (file manager and ad hoc data update) to issue SECURE and DESECURE commands. In this case, you actually need update but not retrieve privileges. (Refer to File security for a discussion of these privileges.)

File and group references

When an explicit reference is made to a file with an IN clause and that file is opened only as a member of one or more permanent groups, the file-level privileges to be checked must be obtained from the group privileges, as defined for every group of which the file is a member. If any group's privileges allow the access in question, then the operation proceeds.

If the access is to a secured procedure, for every group in which the file is opened and the access is allowed by the group privileges, the user's user class in that group is used to determine privileges for that procedure's class. If any group's user class has the privilege, the operation proceeds.

See the discussion of reference context in the example on Determining user access levels and see Files, groups, and reference context for more information.

Subsystem security

When a user enters a subsystem, Model 204 opens and determines privileges for all subsystem files and groups for that user. The files that are opened and the privileges that are assigned are based on a combination of the user's subsystem user class and the subsystem's status, both specified by the system manager in the subsystem definition.

The system manager assigns a user to a subsystem user class by entering the user's Model 204 login user ID in the appropriate subsystem user class. Whenever the user invokes the subsystem, the user is assigned the subsystem command privileges and the file and group privileges of that subsystem user class.

The system manager controls access to the subsystem through the subsystem status: public, semipublic, or private. The status determines which user classes can enter a particular subsystem and whether or not users without a user class assignment are permitted entry.

For more information about subsystems, see System requirements for Application Subsystems.

Terminal security

Model 204 terminal security allows access to certain login user IDs, files, or groups to be restricted to users at certain terminals. For example, you might want a particular MEDICAL file to be accessible only through terminals located physically in doctors' offices.

The terminal security feature allows a list of terminal numbers to be associated with each login, file, or group password. A terminal number is determined during Model 204 initialization by the order of the user parameter lines and the way in which they are assigned to specific telecommunications unit numbers in the JCL.

The batch user (User 0) is considered to be terminal 0 (zero). A user at a particular terminal whose number is n can log in to a specific user ID or open a specific file or group only if the terminal number, n, is in the terminal list associated with the password for that user ID, file, or group. If it is not, Model 204 responds as though the user had entered an invalid password.

Terminal security is generally used with only hard-wired terminals, that is, terminals on leased lines. If an installation has dialup terminals, the terminal can be connected to a number of similar telecommunications units and user parameter lines. In this case, although the location of the terminal can be fixed, its terminal number can change every time it is dialed up.

The entries in the ACT do not take effect for users that have the file open when the SECURE command is issued until they reopen the file. This includes the user who issues the command. The complete syntax and description of the SECURE command is located in the ry time it is dialed up.

By controlling the assignment of terminal numbers to physical terminals, the system manager determines the appropriate terminal security scheme. You provide assistance in limiting file and group access through file passwords and privileges, and group passwords and privileges.