APSYSEC parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (add links)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Template:APSYSEC parameter subtitle}}
{{Template:APSYSEC parameter subtitle}}
==Summary==
==Summary==
<dl>
<dl>
Line 9: Line 10:
<dd>User 0 CCAIN parameters
<dd>User 0 CCAIN parameters
<dt>Related products
<dt>Related products
<dd>Prior to Version 7.5 of Model&nbsp;204, this parameter required the [[SirSafe]] product.
<dd>Prior to Version 7.5 of [[Model 204]], this parameter required the <var class="product">SirSafe</var> product.
<dt>Introduced
<dt>Introduced
<dd><var class="product">[[Sirius Mods]]</var> 6.7
<dd><var class="product">[[Sirius Mods]]</var> 6.7
Line 15: Line 16:


==Description==
==Description==
The APSYSEC parameter makes it possible for a system
The <var>APSYSEC</var> parameter makes it possible for a system
manager to START, STOP, DEBUG, or TEST any subsystem, without have to
manager to <var>[[START command: Starting an application subsystem|START]]</var>, <var>[[STOP command: Stopping an application subsystem|STOP]]</var>, <var>[[DEBUG command|DEBUG]]</var>, or <var>[[TEST command|TEST]]</var> any subsystem, without having to
add the system manager to the sclass authorized to do these things.
add the system manager to the [[SCLASS]] authorized to do these things.
Setting this parameter has no effect at sites not authorized for ''SirSafe''.
 
For versions of Model&nbsp;204 prior to 7.5, setting this parameter has no effect at sites not authorized for [[SirSafe]].


The APSYSEC parameter is a bitmask parameter where the bits mean:
The <var>APSYSEC</var> parameter is a bitmask parameter where the bits mean:
<dl>
<table class="thJustBold">
<dt>X'01'
<tr><th>X'01'</th>
<dd>System managers are allowed to START, STOP, DEBUG, or TEST any subsystem.
<td>System managers are allowed to <var>START</var>, <var>STOP</var>, <var>DEBUG</var>, or <var>TEST</var> any subsystem.
This saves the effort of adding a system manager to a privileged
This saves the effort of adding a system manager to a privileged
sclass in every subsystem in an Online so that the system manager could
SCLASS in every subsystem in an Online so that the system manager could
at least start and stop the subsystems &mdash; a common thing for system
at least start and stop the subsystems &mdash; a common thing for system
managers to need to do.
managers to need to do.
 
<p>
In fact, if no users other than system managers need to start or stop
In fact, if no users other than system managers need to start or stop
subsystems, this can eliminate the need to even have sclasses in a subsystem
subsystems, this can eliminate the need to even have sclasses in a subsystem to allow starting or stopping of the subsystem.
to allow starting or stopping of the subsystem.
In some cases, eliminating this need can reduce the subsystem definition to
In some cases, eliminating this need can reduce the subsystem definition to
a single default sclass, which has performance benefits &mdash; no sclass
a single default sclass, which has performance benefits &mdash; no sclass
lookup is required when a user enters a subsystem, and no sclass-specific
lookup is required when a user enters a subsystem, and no sclass-specific
compiles are done for the procedures in the subsystem.
compilations are done for the procedures in the subsystem.</p>
 
<p>
Because of the overhead associated with multiple sclasses in a
Because of the overhead associated with multiple sclasses in a
subsystem (not huge, but possibly measurable), some sites take the risk
subsystem (not huge, but possibly measurable), some sites take the risk
of adding START and STOP privileges (and perhaps TEST and DEBUG)
of adding <var>START</var> and <var>STOP</var> privileges (and perhaps <var>TEST</var> and <var>DEBUG</var>) to the one and only sclass for a subsystem.
to the one and only sclass for a subsystem.
This, of course, means that any user can start and stop the subsystem, which might not be ideal from a control or security perspective. </p>
This, of course, means that any user can start and stop the subsystem, which
<p>
might not be ideal from a control or security perspective.
The <var>APSYSEC</var> parameter allows such a site to keep one sclass but remove the risk.
 
<var>START</var> and <var>STOP</var> privileges can be removed from the default/only sclass for a
The APSYSEC parameter allows such a site to keep one sclass but remove the risk.
subsystem, and only system managers (or users running subsystems that give them system manager privileges) can start or stop subsystems.</p>
START and STOP privileges can be removed from the default/only sclass for a
<p>
subsystem, and only system managers (or users running subsystems that give
To continue using Model 204's traditional fine-grained
them system manager privileges) can start or stop subsystems.
control of <var>START</var>, <var>STOP</var>, <var>TEST</var>, and <var>DEBUG</var> privileges, the <var>APSYSEC</var> X'01' bit should <i><strong>not</strong></i> be set.</p></td></tr>
 
</table>
To continue using [[Model 204]]'s traditional fine-grained
control of START, STOP, TEST, and DEBUG privileges, the APSYSEC X'01' bit
should ''not'' be set.
</dl>


<!-- APSYXMM - Deprecated -->
<!-- APSYXMM - Deprecated -->

Latest revision as of 17:11, 30 November 2016

Sirius APSY security flags

Summary

Default value
X'00'
Parameter type
System
Where set
User 0 CCAIN parameters
Related products
Prior to Version 7.5 of Model 204, this parameter required the SirSafe product.
Introduced
Sirius Mods 6.7

Description

The APSYSEC parameter makes it possible for a system manager to START, STOP, DEBUG, or TEST any subsystem, without having to add the system manager to the SCLASS authorized to do these things.

For versions of Model 204 prior to 7.5, setting this parameter has no effect at sites not authorized for SirSafe.

The APSYSEC parameter is a bitmask parameter where the bits mean:

X'01' System managers are allowed to START, STOP, DEBUG, or TEST any subsystem.

This saves the effort of adding a system manager to a privileged SCLASS in every subsystem in an Online so that the system manager could at least start and stop the subsystems — a common thing for system managers to need to do.

In fact, if no users other than system managers need to start or stop subsystems, this can eliminate the need to even have sclasses in a subsystem to allow starting or stopping of the subsystem. In some cases, eliminating this need can reduce the subsystem definition to a single default sclass, which has performance benefits — no sclass lookup is required when a user enters a subsystem, and no sclass-specific compilations are done for the procedures in the subsystem.

Because of the overhead associated with multiple sclasses in a subsystem (not huge, but possibly measurable), some sites take the risk of adding START and STOP privileges (and perhaps TEST and DEBUG) to the one and only sclass for a subsystem. This, of course, means that any user can start and stop the subsystem, which might not be ideal from a control or security perspective.

The APSYSEC parameter allows such a site to keep one sclass but remove the risk. START and STOP privileges can be removed from the default/only sclass for a subsystem, and only system managers (or users running subsystems that give them system manager privileges) can start or stop subsystems.

To continue using Model 204's traditional fine-grained control of START, STOP, TEST, and DEBUG privileges, the APSYSEC X'01' bit should not be set.