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