Lennie, The problem is occurring on a system running with a RACF database. This is the second LPAR that is bing converted from Top Secret. The first did not show this problem nor have any other systems we have converted. It really makes me wonder what the SECURITY.SYSLOG.USESAFRECVR SDSF property was created for, as it solves this specific problem.
On Mon, Apr 20, 2020 at 5:21 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > From what you are saying it appears you have a system that uses different > security software at different times. > > I know somewhere between nothing and zero about TSS, but is it possible > that TSS creates SYSLOG with an owner of *BYPASS* and that SDSF was > attempting to access that SYSLOG spool file? > > The entry I referred to previously about *BYPASS* indicated an ACEE for > user *BYPASS* would be created deliberately (and manually) in order to make > use of a REQUEST=EXTRACT RACROUTE call. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Email: lenni...@rsmpartners.com > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Lou Losee > Sent: 20 April 2020 21:24 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] JESSPOOL problem accessing SYSLOG > > I can't answer this right now, as we have re-IPL'd the system with TSS. > The problem occurred during a test IPL with a RACF DB converted from TSS. > The other LPAR we converted has SYSLOG using a user id of +MASTER+. I > have to assume that when we had the problem SYSLOG was running with a user > id of > *BYPASS* since it is the user id that goes into the 2nd qualifier of the > resource being checked. > > My best guess at this point is that SYSLOG is getting created before RACF > is available so it gets a user id of *BYPASS*. > > Lou > -- > Artificial Intelligence is no match for Natural Stupidity > - Unknown > > > On Mon, Apr 20, 2020 at 2:38 PM Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > > Interesting. > > > > Seems to raise 2 questions. > > 1. Why is the 2nd qualifier "*BYPASS*"? > > 2. Why can you not find a profile that will match it? > > > > When I look at all the output on my system (z/OS 2.3) by setting no > > prefix and using the O SDF primary command, I see that the SYSLOG task > > is using a userid of +MASTER+. > > What is yours using? > > > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > > > Web: www.rsmpartners.com > > ‘Dance like no one is watching. Encrypt like everyone is.’ > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > Behalf Of Lou Losee > > Sent: 20 April 2020 20:29 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [IBM-MAIN] JESSPOOL problem accessing SYSLOG > > > > I posted this to RACF-L earlier, but have not received a response to > > help solve the problem so I have decided to cross-post here. > > > > I have a problem accessing the SYSLOG from SDSF on one LPAR. The > > problem appears to be caused by the second qualifier in the RACHECK > > request being > > *BYPASS* when it usually (on other systems/LPARs) is +MASTER+. Here > > is the ICH408I message I receive: > > > > ICH408I USER(THEUSER) GROUP(THEGROUP ) NAME(JOHN SMITH ) > > TST1JES.*BYPASS*.SYSLOG.SYSTEM.TST1 CL(JESSPOOL) > > PROFILE NOT FOUND - REQUIRED FOR AUTHORITY CHECKING > > ACCESS INTENT(READ ) ACCESS ALLOWED(NONE ) > > > > I have tried creating the following JESSPOOL profiles yet still get > > the same error: > > TST1JES.** > > TST1JES.%BYPASS%.SYSLOG.SYSTEM.TST1 > > TST1JES.*.SYSLOG.SYSTEM.TST1 > > > > Has anyone run into this before and have a solution? > > > > Right now the only ways I have found to get around it are: > > 1) Deactivate JESSPOOL (i.e., SETR NOCLASSACT(JESSPOOL)) > > 2) Setting the SDSF property SECURITY.SYSLOG.USESAFRECVR to TRUE. > > > > Lou > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Please excuse spelling - sent from my mobile. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
