General considerations  (updated for server version 4.16 or later)

MOMI is initially launched via an obey file to start the main $MOMI processes.  This process starts other processes that support the MOMI environment.  When a user 'logs on' to a MOMI PC Client, a logon server process is launched that assumes the user id of the person logging on.  If it is necessary to perform a sensitive command, such as viewing a Spooler Job, a process is launched from the logon server to perform the sensitive commands under the users authority and not under the authority of the main $MOMI process.

 

MOMI does not contain privileged code so it does NOT require to be licensed via FUP.  However, in order to execute certain functions of MOMI require additional security (See BWSSG below).

 

There are three general user id classifications.  Super.Super (i.e. 255,255), Super.Group (i.e. 255,*) and all other "normal" User ID's.  You should consider starting MOMI under a "normal" User ID, perhaps one specifically created for MOMI.  However, the use of SAFEGUARD or SQL/MP may require that you operate MOMI under a higher level of authority.

 

Below are the security guidelines:

 

The BWMOMI executable

Must be secured to allow Execute for all users.  For example, a Guardian security string of "UUNU".  Additionally, in order to allow the creation of SAVEABEND files (used in troubleshooting), READ access should also be considered for a resulting security string of "NUNU".

 

The BWMOMI executable Super Group helper

Performs TCP/IP "Ping" or ICMP Echo command and adjustment of system time (if enabled)

Must be secured to allow Execute for all users and PROGID to a Super.Group user for TNS/R systems and Super.Super for TNS/E systems.  For example, a Guardian security string of "UUNU".  Additionally, in order to allow the creation of SAVEABEND files (used in troubleshooting), READ access should also be considered for a resulting security string of "NUNU".

This server is not used if MOMI is started under Super.Super.

 

MOMI creates several work files in the subvolume where the object resides.  The User ID MOMI runs under must have read/write/execute/purge/create access in this subvolume.  It is suggested that SAFEGUARD is not used for this subvolume.

 

MOMI must be given read/write/create access to the subvolume(s) specified for the history files.

 

MEASURE support files

MOMI makes extensive use of MEASURE .  These files must allow read/execute access.

 

EMS distributor program.

Must allow execute access.

 

EMS log file subvolume

In order to display EMS messages from $0, the EMS log files must allow read access.  Use EMSCINFO $0 to display the current EMS log file settings and EMSCCTRL $0,<command> to alter the settings within $0.  Existing EMS log files will need to have their file security altered via FUP.

 

Virtual memory access utility

MOMI uses this to report on virtual memory usage.  The file must allow execute access.

 

O/S release information (i.e. G06.29.02)

Must allow read access.

 

SQL/MP compilation utility

The display of SQL/MP information is the result of dynamic SQL statements.  This file must allow read/execute access.   

 

MOMI provides SQL/MP information by reading this subsystem's catalogs.  MOMI needs read access to all the catalogs on the system, particularly to the Catalog of the System, to provide information on the SQL/MP screens.

 

EMS HTML cause/effect/recovery information

MOMI makes use of this file to display EMS cause/effect/recovery information.  MOMI needs read access to this file.

(This file is not found on pre-S-series systems.)

 

EMS user defined cause/effect/recovery information

MOMI makes use of this file to display EMS user defined cause/effect/recovery information.  MOMI needs read access to this file.  Additionally, a user may also logon and if they have proper security edit this file.  The location of this file may be overridden with the CONFMOMI keyword EVENTCX.