Re: QSYSOPR message queue security

No matter how the messages were deleted. When the *DLT data authority is removed from the *MSGQ object for the user, then the F11 and both of F13 and F16 are disabled for that user; i.e. CPD2419 "Not authorized to delete messages." would be the effect for each of those attempts to delete messages.

And while the missing *DLT data authority also would have prevented the CHGMSGQ DLVRY(*BREAK) request due to CPF2408 "Not authorized to message queue QSYSOPR.", a CLP that adopted authority to allow the CHGMSGQ will have no implications for the function of the "Display Messages" feature. When presented via the explicit command request to DSPMSG or when presented implicitly by an event to present a message in break mode, the "Display Messages" feature is not activated with the CLP that did the adoption, that CLP will not be in the program stack, so the user can not delete messages from the queue. The adopted authority would be in effect only for the CHGMSGQ request.

Regards, Chuck

On 12 Mar 2013 07:18, rob@xxxxxxxxx wrote:

We don't know she cleared QSYSOPR. F13? F16? CLRMSGQ?
If she used F13 or F16 then cute wrappers for DSPMSG aren't going to
cut it. <<SNIP>>

Michael Schutte on 03/12/2013 09:39 AM wrote:
Create a CL for her to call instead.

On Tue, Mar 12, 2013 at 9:37 AM, Jeff Crosby wrote:

Every day our billing clerk serves as the de facto system
operator. When she comes in she does a CHGMSGQ QSYSOPR *BREAK
SEV(30) so that any QSYSOPR messages break to her.

Today she accidentally cleared QSYSOPR. Not a catastrophe but we
don't want repeats.

A google search indicated that removing the *DLT authority would
prevent her from deleting messages or clearing the queue. Great,
except she then was not allowed to do the CHGMSGQ QSYSOPR *BREAK
SEV(30). Catch 22! <<SNIP>