OnDemand Users Group

Support Forums => CMOD for z/OS Server => Topic started by: cleroks on February 05, 2010, 10:54:27 PM

Title: Security exit and menu-building RACROUTEs
Post by: cleroks on February 05, 2010, 10:54:27 PM
How do you differentiate between a menu-building RACROUTE call and a normal access attempt RACROUTE call in the security exit?  Our problem is whenever a user logs in to the OnDemand gui interface a violation record is cut to SMF for every folder the user does not have access to (usually in the hundreds).  I want to not cut those records via the LOG= parameter on the RACROUTE macro for menu-building calls and cut the records for normal attempted access RACROUTE calls.  But the security exit has only one path to the RACROUTE macro call with no differentiation between the two purposes for the call. 

How are other sites handling this?

Thanks.

Bob Young
Title: Re: Security exit and menu-building RACROUTEs
Post by: PasiPK on February 15, 2010, 01:27:24 PM
Hi Bob,
we also had problem in this area, getting a lot of RACF messages to operlog during logon.
In the source code for ARSUSECZ after comments
*  Issue a RACROUTE AUTH request to determine if the user has Read
*  access to the Folder. 
                                       
we added MSGSUPP=NO line to following macro

RACROUTE  REQUEST=AUTH,        Validate access authority      +
      CLASS=WKSAFCLS,          SAF Resource Class area        +
      ATTR=READ,               Authority requested            +
      ENTITYX=(WKENTBUF,NONE), Resource Profile Name area     +
      ACEE=(R2),               ACEE pointer in R2             +
      WORKA=WKRACWKA,          SAF work area                  +
      RELEASE=2608,            OS/390 2.8 level               +
      MSGRTRN=NO,              Do not return messages         +
      MSGSUPP=YES,             suppress WTO -pk               +
      MF=(E,WKRACFPL)               [/font][/font]                           
Title: Re: Security exit and menu-building RACROUTEs
Post by: PasiPK on July 28, 2010, 09:20:48 AM
correction: ofcourse we added MSGSUPP=YES  and not MSGSUPP=NO