S211KENO@HTIKHT5.BITNET (Kees Noyens KUB/DRC/CB) (09/17/86)
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
art@MITRE.ARPA (Art McClinton) (09/23/86)
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=
I tried the above on my VMS 4.4 system. I must admit I am having a
hard time figuring out what you really intended to do. The Allocate
will not work on your own port so am assuming that you are allocating
another terminal line. For security reasons we do not allow this and
if you are concerned with security I suggest that you likewise remove
the ability. {VERY EASY TO BIULD A TROJAN HORSE AND STEAL PASSWORDS}
Assuming that the read is really on another line than I do not
understand why you did not use a SET HOST/DTE to connect to that line
with the full capabilities that you wanted.
I have an outgoing modem line that can be allocated so I tried your
code and indeed it hung such that I could not issue a control Y to
stop it. However when I disconnected (coming in thru ABLE VMZ's and
Sytek LAN 200's) my process was disconnected. I think that the
question is an interesting one for an SPR. My question is one of "Why
can I not interrupt a DCL read on another terminal line?"
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...
I understood you to say that the process was hung and you could not
control Y out of the old process. How will the new person be able to
do what you could not?
NEVER rely on set terminal/modem/hangup
----- for deletion of a (privileged) process.
I agree completely. I have even seen it written that one should never
remotely log onto a computer system using privileges.
- Arthur T. McClinton Jr., (703) 883-6356
The MITRE Corporation, Mail Stop Z305
1820 Dolley Madison Blvd.
McLean, VA 22102