<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I was updating some of MRC's late changes into my version of
PANDA. A (very) few of these were not documented with a change
number, so I had been caught by surprise. While doing this, I
stumbled over some defensive coding that he had put in to keep
even an enabled <font size="+1"><tt>WHEEL</tt></font> or <font
size="+1"><tt>OPERATOR</tt></font> from doing something <i>Really</i>
<i>Bad</i>.</p>
<p>I got to wondering about this, which led me to think about the
use of the <font size="+1"><tt>OPERATOR</tt></font> id, which is
analogous to the <font size="+1"><tt>[1,2]</tt></font> PPN under
Tops-10 and maybe having administrator rights under Windows, not
as bad as root.<br>
</p>
<p>Tops-20, like most mainframe operating systems of the day,
assumed a trained operations staff (as in trained to "DON'T
TOUCH") and a trained systems programming staff. However, this
all-or-nothing approach eventually became more granular with the
implementation of SEMI-OPR capability. I had implemented this at
Columbia several years earlier with <font size="+1"><tt>S</tt><tt>C%LOP</tt></font>,
or Little Operator capability (this was known colloquially as <font
size="+1"><tt>l'opr</tt></font>.) We had a number of training
issues with our operators (some of them literally could not read),
so this allowed them to use Galaxy to mount tapes and paper forms,
but nothing more. PANDA provides administrator capability
(SC%ADM) which allows a certain amount of file system
administration.<br>
</p>
<p>The PANDA access control job (<font size="+1"><tt>ACJ</tt></font>)
already puts certain restrictions on <font size="+1"><tt>OPERATOR</tt></font>,
mainly in the area of login. It occurred to me that the above
assumptions concerning training simply are not true in the current
hobbyist universe. You can actually remove <font size="+1"><tt>OPERATOR</tt></font>
(<font size="+1"><tt>SC%OPR</tt></font>) capability from the <font
size="+1"><tt>OPERATOR</tt></font> id, which will break a rather
large number of things. As a matter of fact, you can delete the <font
size="+1"><tt>OPERATOR</tt></font> id entirely. I'm not sure
you could complete boot up into an sensible state after that; I
guess you'd need to turn on debugging and go directly to <font
size="+1"><tt>KDDT</tt></font> to then recreate the id by hand.
That's training; maybe Monitor Internals level training...</p>
<p>And of course, even trained individuals can do dumb things...
(GUILTY!) So I modified the <font size="+1"><tt>ACJ</tt></font>
further to implement the following policies on a CRDIR% of <font
size="+1"><tt>OPERATOR</tt></font>:</p>
<ol>
<li>May not delete <font size="+1"><tt>OPERATOR</tt></font>.</li>
<li>May not remove <font size="+1"><tt>SC%OPR</tt></font> from <font
size="+1"><tt>OPERATOR</tt></font>.</li>
<li>May not set <font size="+1"><tt>OPERATOR</tt></font> not
login-able</li>
<ul type="disc">
<li><font size="+1"><tt>FILES-ONLY</tt></font> </li>
<li><font size="+1"><tt>INVALID</tt></font></li>
<li><font size="+1"><tt><font size="+1"><tt>CHARGE-LIMITED</tt></font></tt></font></li>
</ul>
<li>May not set <font size="+1"><tt>OPERATOR</tt></font> <font
size="+1"><tt>FTP-ONLY</tt></font> (no way to get to the EXEC;
the normal time-sharing user interface)</li>
<li>May not set 'junk' (I.E., undocumented) bits in <font
size="+1"><tt>OPERATOR</tt></font> directory protection word<br>
</li>
<li>May not set <font size="+1"><tt>OPERATOR</tt></font>
directory protection to allow world read, write or connect</li>
<li>May not clear the <font size="+1"><tt>OPERATOR</tt></font>
password (set to <font size="+1"><tt>NUL</tt></font>)</li>
</ol>
<p>If you're winning enough to defeat these restrictions, then maybe
you're winning enough to understand the ramifications of doing
them.</p>
<p>Comments for other DEC OS's? I don't remember what RSTS, RSX and
VMS do.</p>
</body>
</html>