Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version VT1.00C 11/1/84; site vortex.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!decvax!bellcore!vortex!lauren
From: lauren@vortex.UUCP (Lauren Weinstein)
Newsgroups: net.micro.pc
Subject: Re: IBM Bulletin Board Software
Message-ID: <809@vortex.UUCP>
Date: Mon, 23-Sep-85 22:48:47 EDT
Article-I.D.: vortex.809
Posted: Mon Sep 23 22:48:47 1985
Date-Received: Thu, 26-Sep-85 06:22:35 EDT
References: <467@ecsvax.UUCP>
Organization: Vortex Technology, Los Angeles
Lines: 33

The key point is that it is certainly possible for people to set up
any UULINK remote login user to run whatever programs might be desired.  

My primary goal in remote access was to make sure that the primary UULINK
remote access program itself could be run safely and reliably.
Later, I added "generalized" remote access capabilities for 
other programs that people might want to run remotely, but it should
be remembered that "generalized" remote access is always a problem with 
MSDOS due to the way many programs behave (e.g. playing around with
memory in odd ways, etc.) and the lack of memory protection in MSDOS.

There is no problem if properly written programs are executed automatically
for particular remote login users.  The best example of this is the
UULINK "uucico" remote access program itself which is the most commonly
run program for incoming callers.  This program takes direct control of 
the COM ports and is very secure and reliable on the system since it was
written with remote access in mind from the start.  Running the UULINK
"uucico" via remote login is very secure.  In fact, it provides
a higher level of security than is found on many Unix systems.  The program
takes great pains to preserve the runtime environment of the system and keep
MSDOS running smoothly.  It was this program that was my primary
concern for remote access, but I decided to allow more "generalized"
remote access as well for whatever "special" applications people might
want remote login users to be able to run.  It is of course up to the
people who set up these remote users to determine what sorts of users
(and programs) they want to allow to access their systems, and through
what sorts of control programs.

More detailed questions on this topic should probably be sent to
me directly--I think we're starting to get into too much detail
for this newsgroup.

--Lauren--