Re: QSYSOPR message queue security

[CRPence <CRPbottle@xxxxxxxxx>]

  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>