After I got done 'enough' with the modifications to Tops-20 DAPLIB to
support auto-mounting and dismounting of regulated structures, I turned
to putting the indicated hooks into the ACJ to catch the mount requests
and was quite surprised to find something.
There are two types of structure mounts on Tops-20, job-wide (.MSIMC)
and fork-only (.MSICF), the difference between the two being that if you
do the former (.MSIMC), any fork in the job can get a JFN on a file in
the structure while the latter (.MSICF) only allows the fork that did
the mount to do it.
As currently architected, Tops-20 FAL is a multi-forking server, so it
can't do a job-wide structure mount as that would allow other forks in
the job to access files on a regulated structure, thus by-passing
accounting and access control. "No problem", I thought, "I'll just use
.MSICF to do the fork mount." I was looking forward to that because I
don't recall ever seeing it be done by anything. Galaxy (MOUNTR)
doesn't support fork-only mounts, which is where mount requests are
almost universally handled.
Nothing like blazing new trails four decades after the fact! Boy was I
surprised to find that the monitor only provides a hook (.GOSMT) for
the job-wide case! That's right, if you do a job wide mount and either
use Galaxy do it for you or do it yourself with .MSIMC, the ACJ gets
control. Do it fork-only by yourself with .MSICF, and the ACJ doesn't
know anything about you...
I'm not sure that I'm thinking about this the right way, but right now
it is just plain peculiar. A quick search through all my sources shows
why I never saw this back in the day: there isn't anything that does use
.MSICF, so no help there.
Of course, I'm certainly not above putting another ACJ hook into the
MSTR% JSYS, but before I go get into that, I thought I'd ask about it.
Why would you hook a job-wide structure mount and not a fork-only one
when the purpose of the hook is to determine whether policy allows you
to do a mount?
Puzzled,
--T
------------------------------------------------------------------------
On 4/15/23 7:45 PM, Thomas DeBellis wrote:
The DAP 5.6 specification (28-Mar-1980) does not appear to have much
information concerning device mounting.
It's not clear how much DAP was designed to be concerned with such
activities, but it would appear that it implicitly expects that any
device that is available is usable. There are some bits in the File
Access Options (FOP) and Generic Device Characteristics (DEV)
attributes that have some information concerning mounting, viz:
*Attribute*
*Bit*
*Name*
*Meaning*
FOP
13
FB$DMO
Rewind and dismount magnetic tape on close.
DEV
10
FB$MNT
Device is currently mounted.
DEV
11
FB$DMT
Deviceis marked for dismount.
So assuming you are accessing a magnetic tape, you can request that it
be rewound and dismounted when closed and you can get some information
concerning mount status.
At this time of DAP design, large systems basically lived on tape and
disk mounts, given the expense of the devices to actually read and
write their respective media. There was a cost for a mount, but if
you were using a lot of space, it could pay to have your own media
where you wouldn't get hit with the storage costs.
Mounting structures is also a well understood mechanism to provide
additional access control granularity.
A "regulated" structure on Tops-20 can not be used unless it is first
mounted by the user. It may be spun up and online, but if it is
regulated, you must mount it first. This gives you the opportunity to
put policy on the mount with an access control request. At Columbia,
nobody was allowed to mount the (regulated) staff structure (CU:, an
RP07) unless they were staff. Students were not allowed to mount
anything. Paying customers could mount non-domestic regulated
structures. I wrote the code for the 'Judge', our access control job
(or ACJ) which did this as it required some hooks in Galaxy (Quasar
and MOUNTR).
FAL is not subject to such ACJ policy because it specifically informs
Tops-20 to by-pass mount counts. So that's kind of a back door
because you could use FAL to snoop around regulated structures, which
is exactly what we didn't want to be happening. It bothered me, but
not enough for me to tell management that it should be addressed.
I was fixing a bug in FAL ANONYMOUS processing when I recalled this
and it began to bother me more. I don't want regulated structures
being implicitly used. My extended mode FTP server does not bypass
mount counts and this is what keeps web crawlers from snooping through
every file I have. You have to explicitly know the structure name and
request it with an SMNT verb which you can then put policy on. So I
scratched the itch and implemented a MOUNTING command with the
following options:
* BYPASSED, the current FAL behavior: use whatever is online.
* PREVENTED, respect regulated structure mount counts and fail if
the structure isn't mounted.
* AUTOMATIC, attempt to mount the structure on the behalf of the
user where necessary.
PREVENTED is the most restricted, as a FAL job only has access to
unregulated structures (which require no mounting). So that's good.
AUTOMATIC maybe gets you the best of both worlds. You can access
online structures provided policy allows you to, elsewhere which means
that users that expect to be able to mount structures will have this
done for them. I have yet to put in another command to restrict
ANONYMOUS usage, in other words, forbid automatic mounting for ANONYMOUS.
Is my reading of DAP is close enough? How do other DEC operating
systems handle this? I know VMS can handle disk and tape mounts, I
forget about RSTS, RSX and RT.