30 Mar
2022
30 Mar
'22
12:41 a.m.
RSX don't have anything equivalent to spying on another terminal.
Of course, someone could write a program that would enable you to do it,
but I haven't seen one, and this would then be some non-DEC hack. Doubt
that would be very relevant.
Johnny
On 2022-03-30 00:38, Thomas DeBellis wrote:
I was finishing up with the Access Control Job (ACJ)
modifications for
MINI-EXEC Access (SC%MEA capability) when I got to thinking more about
the console.
For 36 bit machines, there has been some historical inconsistency about
messages that come up on the console but only on the console and nowhere
else. Under Tops-20, one example was BUGINF and BUGCHK messages, which
you had to be near the console to see. Enhancements were eventually
made to Tops-20 distribute these via Orion to all Galaxy operators,
which is a nice idea as it also puts them in them into the
OPERATOR-SYSTEM-LOG in PS:<SPOOL>. It's also essential in a cluster.
However, there are still those other pesky messages, which maybe you
need to do something about. One example is "*DDMP swap space low
action*", which can occur if you happen to have a number of
multi-section programs executing and don't have enough swapping defined
(I.E., you took the defaults). You can wind up with a crashed machine
if you don't release some memory.
Under Tops-20, there is a program called CTYPEEK that uses the TLINK%
JSYS to allow terminals to 'spy' on the console via one way links. For
a number of reasons, I am uncomfortable with spying. You certainly need
to spy when you are debugging protocols; I've used it for both the
Extended Mode FTP server and Tops-20 Kermit. Think of it like a
Tops-20-centric Wireshark without the formatting.
On the other hand, when you get too many people with SC%WHL or SC%OPR
and too many 'personalities', you start to need _accountability_. In
short, I'd rather have it logged someplace that somebody is */spying/*.
CTYPEEK is unusual because it's one of the few programs that MRC put on
the PANDA distribution that has no source code immediately available.
That is unfortunate because having a program—/any/ program—that must run
with SC%WHL or SC%OPR enabled with no source code has been bothering me.
Some sleuthing turned up an email that Kirk Lougheed posted to Tops-20
Wizards in August 2nd, 1982 2316-PDT, nearly four decades ago (!!). It
was short enough that I did a complete rewrite, getting some additional
functionality. That actual list of enhancements is as follows:
1. More effective error reporting, debugging and some recovery.
Debugging entry which will not do the actual link.
Exported entry for symbol table fix up for EXEC (when debugging).
2. Granular capability management.
3. Standard CTY discovery via STDEV% JSYS (original monitor SNOOP%
and PEEK% probing kept as fall back)
4. Logging to CTY standard to inform of monitoring by whom.
Notification of batch logging given to CTY (see below)
Silent reentry point to not advise console of said monitoring.
5. Checking of existing CTY links and not re-link if already linked.
Cuts down on GETOK%'s to ACJ
Advise user of preexisting link (and do not log on CTY)
6. If CTY links are full, advise of terminals doing monitoring
7. Clears pause-on-command and pause-on-end-of-page on CTY and
user's TTY
8. Standard use of 'modern' program data vectors (PDV's)
9. Write-protected PDV, CODE and SYMBOL .PSECT's (analogous to
Tops-10 high segment)
10. Detection of whether running in a batch stream.
If running in a batch stream, waits in a THIBR% JSYS for
18:38:28.864
Allows use of a batch stream to log to a file;
Batch log duration time and finish time in batch log
Allow early wake up via TWAKE% (so don't have to cancel the job)
_Some sample output_:
28-Mar-2022 20:33:53 Console terminal (TTY5:) being monitored by
SLOGIN, TTY46:, Job 11
% Console terminal (TTY5:) is already being monitored by you:
SLOGIN, TTY45:, Job 10
20:23:19 USER [Console terminal (TTY5:) being monitored by SLOGIN,
TTY21:, Batch Job 9]
20:23:19 USER % Will monitor a maximum of 18 Hours, 38 Minutes, 28
Seconds and 864 Milliseconds.
20:23:19 USER Monitoring will be discontinued on Sunday, March
13, 2022 4:01:48PM-EDT
Which is how I logged the EST to EDT transition (possibly the last one!)
How do other DEC timesharing systems handle this?
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------------------------------------------------
On 3/28/22 6:45 PM, Thomas DeBellis wrote:
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.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
------------------------------------------------------------------------
On Mar 7, 2022, at 3:56 PM, Thomas DeBellis <tommytimesharing(a)gmail.com>
What about other DEC multi-user operating systems? Do you have 'magic'