Is it possible to protect the DB2 Console command #STOP DB2 via permits in Top Secret?
search cancel

Is it possible to protect the DB2 Console command #STOP DB2 via permits in Top Secret?

book

Article ID: 53341

calendar_today

Updated On:

Products

Cleanup Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ECOMETER SERVER COMPONENT FOC Easytrieve Report Generator for Common Services INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware Top Secret Top Secret - LDAP Top Secret - VSE

Issue/Introduction

Description:

I would like to protect db2 commands issued from a console
#stop db2
can I protect this with opercmd?

I tried using opercmd(#sto), and opercmd(mvs.#sto), I already have
opercmd(mvs.stop.) defined.
But none of these rules are being picked up.

Solution:

The only way to prevent the stopping of DB2 is by ensuring that the users who attempt to stop DB2 have either:

STOPALL privilege
SYSOPR authority
SYSCTRL authority
SYSADM authority

Note that when the commands are issued from the MVS console, it is only the issuers authority that is checked and not that of secondary auth IDs.
But there is no way to control the actual issuance of the command - only whether the command will be successful or not.

This is due to the fact that the commands issued to the console do not go through standard "MVS" operator command authorities as they are directly intercepted by the DB2 subsystem.

The above listed authorities are set within DB2.

So that means that CA Top Secret cannot be used to control who can stop DB2 - it is dependent on the operator's internal DB2 authority.

Environment

Release:
Component: AWAGNT