Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!HTIKHT5.BITNET!S211KENO
From: S211KENO@HTIKHT5.BITNET (Kees Noyens KUB/DRC/CB)
Newsgroups: mod.computers.vax
Subject: VMS: security
Message-ID: <8609200747.AA00803@ucbvax.Berkeley.EDU>
Date: Wed, 17-Sep-86 09:27:00 EDT
Article-I.D.: ucbvax.8609200747.AA00803
Posted: Wed Sep 17 09:27:00 1986
Date-Received: Sat, 20-Sep-86 07:13:24 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 33
Approved: info-vax@sri-kl.arpa

We currently run VMS V4.3 on a cluster (2 11/785, 2 11/750).
Most of our terminals are connected through a Datus 5810 portselector
to DHU and DMF ports, which are defined with the
SET TERMINAL qualifiers /MODEM/HANGUP .
If, for some reason, <CTRL> Y does not have the desired effect, we
sometimes use a portselector control sequence to logout.
Under most circumstances this works fine:
the terminal is disconnected from the portselector, the portselector
sends a modem signal which is recognized by the DHU or DMF and
VMS deletes your process.
However, try the following:

$ allocate txa terminal
$ open/read ter terminal
$ read ter line

Now <CTRL> Y doesn't work (anybody knows why not ?) so we try to logout
with the portselector control sequence. The terminal is disconnected and
everything seems fine. However, the old process is still there (LEF-state)
and we have to terminate it with stop/id=
What worries us is that everybody who logs in may accidently connect to
such an old process, if the portselector selects that particular port
on which that process was logged in.
You can imagine what happens if that process has some nice privileges...

NEVER rely on set terminal/modem/hangup
-----         for deletion of a (privileged) process.


=========================
Kees Noyens
Tilburg University
The Netherlands