[HECnet] Anonymous FAL (Tops-20)

Thomas DeBellis tommytimesharing at gmail.com
Wed Jul 3 19:01:56 PDT 2019


Tops-20 is vastly different from Unix (and I believe also VMS) as to how 
it manages user ids and accounts.  Parts of the authentication paradigm 
are very tightly woven into the the file system.  Briefly,

  * A user id is a login-able directory (I.E., one that doesn't have a
    password and is not set FILES-ONLY).  In addition to basic OS
    restrictions which prevent you from viewing file system meta-data
    unless you have appropriate authorization, an access control job
    (ACJ) is layered on top of this which can even restrict privileged
    users.
  * Accounts are either validated out of a binary accounting file in
    monitor space (which is compiled from ASCII source) or via the ACJ. 
    Accounts can have multiple users or systems processes (such as
    spoolers) creating billing records. Users can switch between
    accounts on a per-job, per-fork and intra-program basis (a program
    can decide to bill certain portions of its activity to different
    accounts).
  * The obvious benefit is that there is no password file to attack or
    steal and you can't even tell that there is an accounting file;
    probing passwords is monitored and a certain amount of intervention
    is done.  It is /extremely/ fast. No /etc/passwd to grovel.

However, a deleterious side-effect is that once an id is created, it can 
be used for _anything_, including online interactive login.

On a PANDA monitor, is possible to specify a user id as FTP-ONLY, but 
neither the supplied 5 series ACJ nor the EXEC do anything with it.  
Historically, the Tops-20 FTP server implemented ANONYMOUS usage by 
parsing for the login user atom ANONYMOUS and then swallowing anything 
for the password (what was typically supplied was an email addresses). 
This was then hardwired into a local id.

Artifacts of this still exist in certain browers.  Guess who supplies 
IEUSER@ as the email address password for ANONYOUS usage?

I recall that this is the approach that we had to use with Tops-20 FAL.  
The Extended  Mode FTP server that I wrote is configurable via a file to 
specify the underlying id and password.  More productization would 
probably including having the ACJ enforce FTP-ONLY on LOGIN% or CRJOB% 
and having the EXEC parse for and display FTP-ONLY.  Probably about two 
weeks' part time work as I recall.  Might have to consider Batch policy.

One approach here could be to lift the ANONYMOUS code out of EFTPSR and 
drop it into FAL and then do the changes to the ACJ and EXEC. I'm just 
surprised none of the HECnet Tops-10 or Tops-20 nerds have done it 
(there is some commonality in some of the sources).

Since Tops-20 has a BLISS compiler which implements BLISS COMMON (my 
first training at DEC as an employee was to write code that would cross 
compile under VMS, RSX, Tops-10 and Tops-20).  I think it might be 
useful to review some of the VMS DECnet source, if any of that is 
available.  It might be possible to lift some functionality, which could 
be fun.

Does the VMS hobbiest license get you source code?
> ------------------------------------------------------------------------
> On 7/3/2019 7:21 PM, Johnny Billquist wrote:
>
> VMS, as someone else mentioned, have a default account for FAL.
>
> RSX does not have that.  However, you can use proxy access in RSX to 
> achieve something similar.  Enable incoming and outgoing proxy, and 
> define a default account that incoming requests should be using that way.
>
> If TOPS-20 can do this I don't know.  But it's a suggestion for 
> something else/more to check.
>
>   Johnny
>> ------------------------------------------------------------------------
>> On 2019-07-03 14:15, Thomas DeBellis wrote:
>>
>> I have some software that I'd like to post, but don't recall how to 
>> configure FAL to allow for an anonymous connection; to download from 
>> a restricted directory.
>>
>> I know how to do it for the FTP server (seeing as I wrote it), but 
>> ... different code base.
>>
>> I can only vaguely remember what we did for CCnet at Columbia 
>> University in the 1980's, but I think it was kind of a hack.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20190703/4d7da3f4/attachment-0001.html>


More information about the Hecnet-list mailing list