[HECnet] Re: How special is your CTY? (Part 2)

I've had some time to read all the comments and digest them. This was extremely informative; _all_ of it. Because the KL architecture implies a separate front end, that front end itself must be secured.  If you can get into RSX20F or its equivalent (meaning the parser for KLH10 or SIMH), then the party is really over.  So this implies passwording the front-end, and maybe that's not a great idea.  Ditto if you have an operative switch register; that would need to be disabled and maybe that's not possible or worse maybe it's a downright terrible idea. On the other hand, once you have the system all nicely configured, you really don't want somebody bumping into something and getting you into a situation where you have to do a recovery. Now unfortunately, as a hobbyist, that most likely somebody is…me‼️ Yet, this was also historically true.  We wrote a lot of defensive code to keep the requirement to have WHEEL (SC%WHL) or OPERATOR (SC%OPR) capabilities to an absolute minimum and some amount of code to keep somebody with these capabilities from blowing something away.  Most of the time we all ran with capabilities off (which I still do) to challenge ourselves to implement functionality that didn't require access to everything.  This was the reason for SEMI-OPERATOR (for Galaxy access, we called it LOPR for Little Operator or l'opr). When I looked at the MINI-EXEC, I realized that the only 'dangerous' thing in there was the "*/*" (forward slash) command, which puts you into MDDT (monitor DDT).  Yeah, we don't want to be bumping into that... Otherwise, after the initial system build, the only thing that the MINI-EXEC is used for is debugging top-level EXEC problems. There is nothing about DDT'ing the EXEC that should need WHEEL, so requiring it is complete overkill.  Therefore, like LOPR (SEMI-OPERATOR), I have defined another capability called SC%MEA, for _M_ini-_E_xec _A_ccess.  If you have an EXEC developer, then you just give him/her/it SC%MEA and that's really all you need. I enhanced the ACJ to check for both SC%MEA and SC%WHL and reject if the top-level fork does not have at least one of these and have it enabled.  A not-logged-in job is rejected in all cases, no exceptions. The CTY still remains somewhat special.  If you are running on the CTY, then all that is necessary is to have either SC%WHL or SC%MEA, but not necessarily enabled.  This is to handle the case of an EXEC that blows up early in the login process so that debugging is possible (or to replace the EXEC).  This is similar to GETAB%/SYSGT% (SC%GTB) capability (which is what you need for SYSTAT to work).  All that is necessary is to possess it; it need not be enabled. This is obviously not a 'cure', but rather more of a preventive measure; I don't see that there can be a 'last word' on the subject.