Lou This problem is caused by the SYSLOG outputs that were created when the LPAR was running under TSS still being on the spool.
If you look at the system logs when running under TSS, you will most likely see some IEF196I messages for SYSLOG output dataset creation with *BYPASS* in the name. When that system is then IPLed under RACF, and a user attempts to access those datasets, the owner of *BYPASS* is used and this explains the messages that you are seeing. As to why you are getting *BYPASS* when running TSS, I am not sure. Perhaps something to do with the IPL sequence or started task userid assignment ? It might be worth checking with CA-TSS support. There are a few suggestions to help resolve this : (1) Offload and purge all previous TSS owned SYSLOG outputs before you IPL under RACF (2) Use the SDSF property which forces the SAF check to use the RECVR and RTOKEN of the caller rather than the owner. (3) Use "LOG O" for OPERLOG instead of "LOG S" I suggest option (1) Rob Scott Rocket Software -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Lou Losee Sent: Tuesday, April 21, 2020 1:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JESSPOOL problem accessing SYSLOG EXTERNAL EMAIL 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: > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rsmpartners.com%2F&data=02%7C01%7C%7C9245181bdd7542f7798d08d7e58e744e%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637230272333312235&sdata=vKp8lfxVx871hkuwW5sxI1GFBGq%2BOr7pl%2BL9NM9vtHw%3D&reserved=0 > ‘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: > > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rsmpartners.com%2F&data=02%7C01%7C%7C9245181bdd7542f7798d08d7e58e744e%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637230272333312235&sdata=vKp8lfxVx871hkuwW5sxI1GFBGq%2BOr7pl%2BL9NM9vtHw%3D&reserved=0 > > ‘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 ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
