Nope, no shared spool. Harping is welcome. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown
On Tue, Apr 21, 2020 at 7:36 AM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Lou, > Sorry to harp on about this, but these systems do not share a spool do > they? > > 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: 21 April 2020 01:54 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] JESSPOOL problem accessing SYSLOG > > 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 > > ---------------------------------------------------------------------- > 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
