Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!philabs!klb
From: klb@philabs.Philips.Com (Ken Bourque)
Newsgroups: comp.os.vms
Subject: Re:  DCL DECnet command procedure
Message-ID: <2000@briar.Philips.Com>
Date: Tue, 24-Nov-87 14:44:06 EST
Article-I.D.: briar.2000
Posted: Tue Nov 24 14:44:06 1987
Date-Received: Sun, 29-Nov-87 08:26:03 EST
References: <8711231109.AA29035@ucbvax.Berkeley.EDU>
Reply-To: klb@briar.philips.com.UUCP (Ken Bourque)
Organization: Philips Laboratories, Briarcliff Manor, NY
Lines: 13

In article <8711231109.AA29035@ucbvax.Berkeley.EDU> DEMAR@FNALE.BITNET writes:
* 
*     Last week there was an inquiry from BEN@VMSA.TECH.AC.IL about a DCL
* command procedure that can be used to examine remote DECnet systems.  I want
* to add a word of warning about the use of this type of program.  It works by
* sending a copy of itself into the default account of the remote system, then
* utilizing task-to-task communication between the two programs.  It is a
* primary weapon of hackers; and, infact, is a form of hacking in its own right
* since the user is copying and executing a file on a the remote system without
* any authorization to do so.

For this and other reasons, I think that default DECnet access should be
enabled on an object-specific basis (and not for FAL if at all avoidable)
rather than on a system-wide basis.-- 
Ken Bourque    klb@philabs.philips.com    ...!{uunet,ihnp4,decvax}!philabs!klb