Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!cbosgd!ucbvax!HTIKHT5.BITNET!S211KENO
From: S211KENO@HTIKHT5.BITNET
Newsgroups: mod.computers.vax
Subject: security problem on unibus-fault
Message-ID: <8511111836.AA09079@ucbvax.berkeley.edu>
Date: Mon, 11-Nov-85 17:44:37 EST
Article-I.D.: ucbvax.8511111836.AA09079
Posted: Mon Nov 11 17:44:37 1985
Date-Received: Tue, 12-Nov-85 04:49:53 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 20
Approved: info-vax@ucbvax.berkeley.edu

Security-problem caused by faulty Unibus.

We run a VAX 785/785 cluster, both processors connected to an Ethernet and
equiped with two Unibus's. Last week DECNET started complaining via OPCOM
about the lost Ethernet circuit UNA-0. Also some DHU/port-selector connections
were dropped. Operations decided to do a reboot. This did not solve the problem,
so remote-diagnosis and field-service were called. They quite soon concluded
one Unibus was gone, replaced one board in the DW780 Unibus Adapter and thus
solved that problem.

The thing that worries me is, that upon the reboot all "floating" comms devices
(in our case the DMF32's and the DHU's) in the second, working Unibus were
assigned device-names (TXAn TXBn etc) which were normally on the defective one,
causing print-output to be spooled to terminals etc. Even worse, users claim
these reassignments happened dynamically: without any warning some terminals
were connected to someone elses process (before the reboot).

Because I cannot reconstruct the situation (can I?) I would appreciate any
comments, also, does anyone take special messures to avoid similar situations
on an unattended automatic reboot?