Conference noted::hackers_v1

    There are lots of methods to do what you want (see note 332.*),
    but this is my favorite.  Do a SPAWN/NOWAIT on this:
    
$	SET NOCONTROL=Y
$10$:	WAIT 00:01:00
$	GOTO 10$

    It racks up enough activity every minute to fool SPIRIT into thinking
    you are doing something.  Caution:  I have been told that the IPM
    supplied with SECURPACK is not fooled by this method, but it works
    fine with SPIRIT.
    
    -Bob

    	Complain to your system manager to have it removed, and to his
    manager if neccessary. Point out the affect on your productivity.
    
    	The only significant resource an idle terminal takes on a
    reasonably tuned system is a scarce dial_in line. An idle terminal
    is not insecure if it is LAT locked, if the owner is sitting next
    to it, or it is in a locked room. Since it is not possible for VMS
    to identify any of these conditions, the system manager should.
    
    	When I was system manager of a fairly large cluster I used to
    monitor manually for idle terminals, and when I found one I would
    walk round to it, log out any current sessions, and then disable
    the account that was using it. If I was prevented from doing this
    by a locked LAT session or a threatened punch on the nose then the
    terminal was sufficiently secure. If I was not prevented from doing
    this, the user might have to explain to his manager why he needed
    his account re-enabled (if I was feeling nasty :-}  ).
    
    	You have a lazy system manager.
    

    ref .2
    
    I should think one would hesitate to cast stones without a more
    intimate knowledge of the situation.

    I believe that SPIRIT-type programs tend to make the USERS lazy.
    We used to run SPIRIT here on one of the machines in Los Angeles,
    and after a while an attitude of "I never have to logout - SPIRIT
    will take care of it for me" developed.  After that, I saw even
    more users leave terminals unattended than before SPIRIT was being
    run.
    
    I too think the system manager should take a somewhat active role
    in making sure users don't leave unattended terminals.
    
    -Bob

    re: .2
    	Yes, I should have expressed the opinion as more of a vague
    generalisation.  I had already stated that I consider scarce dial_in
    lines as a valid reason for using something like SPIRIT, and maybe
    that is the case here. Can SPIRIT be restricted to only operate
    on a named set of terminal lines?

< Note 519.5 by PASTIS::MONAHAN >


    re: .5
		The program called AUTOLOGOUT in the toolshed can
	do just what you want and much more.

							Dennis

    	You can use BUSY from the TOOLSHED.
    
    	Advantages:	Terminal is "locked" from unauthorized acces
    
       			People can leave messages
    
    			Broadcast messages are trapped for you
    
    			You can configure it for refresh period,
    			 when to log you out (eg after 6pm)
    
    -mike

    Simply going into NOTES or TPU is generally good enough. There are so
    many ways to fool programs like that that it's no longer an
    intellectual challenge to come up with new ones. 
    
    Also, Spirit-like programs can really do horrid things to you, like
    corrupt databases and indexed files. You really shouldn't do a $DELPRC
    to a process without good reason. $DELPRC is a big hammer that makes
    RMS, DBMS, and other exec-mode code have to panic. We in VMS
    development recommend against using them, as they're easy to thwart and
    can corrupt data. 
    
    	Jon

>    RMS, DBMS, and other exec-mode code have to panic. We in VMS
>    development recommend against using them, as they're easy to thwart and
>    can corrupt data. 
    
    We in I.S. recommend against using them too - just try to repair
    a corrupted database which got corrupted because a "SPIRIT" didn't
    detect a subprocess which was doing updates and killed the parent.
    
    /pjh

    Ahem. I don't like to open myself to the type of flaming I could
    be asking for but...
    
    Can't you guys think of any good reasons to use an idle process killer?
    What if you make sure that all the problems listed are covered?

    Such as:

    	Do a $forcex before the $delprc and make sure the process has
    the right rundown routines defined. Check to see if the process is 
    in DCL rather than some image when the $delprc is done.

        Exclude the users that have "proven" that they will secure their
    terminals when they leave them unattended. 

    	Exclude sensitive images from the list of eligible processes
    to kill.
    
    I've known a lot of system managers (was one once) and haven't met
    many that were lazy. On the contrary...
    
    I have been requested by my management to start having the system
    managers use an idle process killer on our systems. All as part
    of a big push to provide "system security". 
    
    The problem is that there is a lot of sensitive data on our machines
    (as on most others here at DEC) and we have lots of non-DEC employees
    in our building at all times of the day and night. Starting with
    the cleaning people, the Air Forces guys working on a demo/benchmark,
    and the almost daily customer tours through the building.

    I've never liked idle process killers, been bitten by them on more
    than one occasion, but I can almost understand why they might need
    to be used. 
    
    I guess what I'd like to hear is, can the pluses outweigh the minuses
    in this, or are idle process killers the wrong solution?

    							Has3
    

Of some interest in this topic is information picked up rather casually
from a DBMS TSC support person.  Apparently, with DBMS 3.2, doing a $DELPRC
or STOP/ID on an active DBMS user will corrupt the database.  He advised using
$FORCEX to accomplish this.  Those who are running SPIRIT or other idle
process killers on systems which have DBMS databases should be aware of this
possible "gotcha".

	re: .10
        	I hope the previous replies have made it clear that someone
    technically competent and motivated to do so can foil an idle process
    killer. Someone not technically competent can probably get something
    from a friend.
    
    	Someone motivated to keep the system secure can lock a LAT session,
    or log out with very little trouble. This is the best solution,
    since it uses least system resources and avoids the disasters that
    can be caused by deleting the wrong thing.
    
    	SPIRIT lies between the two. It can only work if your users
    are not motivated to foil it, and it is only any use if your users
    are not/cannot be motivated to do the right thing. During the day
    when you have customers around the best it is doing is reducing
    an hour exposure at lunch time to about a quarter of that. You would
    get the same reduction of exposure by finding who does not log out
    during lunch time and persuading three quarters of them to change
    their habits.

    <Deliberately exaggerated viewpoint follows. Caveat lector.   :-)>
        
	SPIRIT is an attempt to provide a technical solution to a problem
    with motivating people, and as such it is inferior to propaganda,
    threats of dismissal, hypnosis, or even just talking to people.
    It is a solution to the problem where the users cannot be motivated
    to do anything, so why not just close down the site?
    

    Having written one one of these beasts, and believing that I was
    NOT a lazy system manager (that is, if you don't consider working
    60+ hours a week lazy ;^). I agree with Harry.
    
    Some of these have a useful purpose in life.  Recently, it was
    suggested to me that an alternative to $DELPRC be implemented, and
    I am seriously considering it.  The enhancement was to simply
    DISCONNECT the process from the virtual terminal to which it was
    connected.  
    
    In this way, you could log in at a later time, and reconnect to
    the disconnected process.  How's that to solve the "I hate this
    because I always have to log in" beef?
    
    -- Nestor

    re .10, .13:
    
    Excuse me for impugning your competence. I'm sorry; I didn't mean to.
    Long before I was a VMS developer, I was a VMS system manager, and I
    wasn't terribly lazy, either. I even wrote my own idle process killer,
    at the behest of a customer that had hired me as a SWS resident. At the
    time, I thought it was a reasonable idea. However, I now think that
    process killers are a bad idea. Let me give you some reasons: 
    
    (1) They are trivially easy to thwart. This conference is full of ways
    to do it, in this topic and in others (this discussion came up about a
    year ago). 
    
    I'll even add another easy way to avoid a process killer -- TPU.
    Sitting here on my �VAX II, a broadcast of one line from ^T will
    consume .03 seconds of CPU time and do 3 I/O's. Getting a two-line
    REPLY is 7 I/O's and .10 CPU second. That's good enough to fool most
    process killers, which usually give warnings. If they don't, they
    should. 
    
    If you can't catch an idle process in NOTES, (while distinguishing
    someone merely being pensive) then it's not much good. Even if you can,
    writing twenty lines of TPU will hack up a subprocess that can eat
    arbitrary resources. It's even easier in DCL. 
    
    Process killers are not security measures any more than putting a wire
    bread tie over a hasp is a lock. 
    
    (2) They corrupt data. Doing a $DELPRC can corrupt RMS or DBMS. $FORCEX
    isn't really much better. You might leave someone in TPU with a bad
    journal file. You'll make a session in Sight, Datatrieve, etc. go away
    completely. Unless a program has been written to take account of being
    interrupted, you may make it corrupt data. This includes disconnecting
    a terminal. Even if you can do it in a supported, reliable way, you're
    merely passing the buck. Once TTY_TIMEOUT expires, the process is going
    to get killed, only this time by the terminal driver. 
    
    Any tool that even *might* corrupt someone's data should clearly be a
    bad idea. It is the job of all of us professionals, engineers and
    system managers alike, to make sure that the users do not lose their
    work. I'm feisty on this issue for that reason. To me, anything else is
    like the people who destroyed the village to save it. I understand that
    there are times you have to destroy villages. (For example, suppose
    someone has left a terminal on and you have to shut the machine down.)
    I just don't think it should be called anything other than what it is. 
    
    If I were a user on a system using a process killer, I would use this
    reason to justify running a thwarter, and tell my management that I was
    doing so. My time is too valuable to have to re-do it; the work I do
    for Digital is too important to have it destroyed. 

    (3) They're the wrong solution to the problem. The problem is a people
    problem. M. Monahan said it quite well in .12. 

    To sum up: they don't work, they corrupt data, and it's a technological
    solution to a management problem. In my opinion, any one of those
    should be good enough to warrant storing them on the null device. 
    
    	Jon Callas
    	VMS development, VMS exec group.

                Ok, you  have  all  convinced me to reconsider my 
                position on SPRIT  (or  in  my  case,  CHIPMUNK).  
                However, not all users  will  be  cooperative  in 
                sharing systems accessability.
                
                So,  is  there  a job  which  will  monitor  idle 
                processes and send me mail when a process exceeds 
                "n"  minutes/hours  of idle time, so I  can  deal 
                with  the  users  on  an individual basis ?    Or 
                perhaps  a    daily   report  (instead  of  mail) 
                summarzing users/idle process time ?
                
                Warren
                VWO I.S. Site Services Manager

    re .13:
    
    Nestor, I never considered you to be a lazy system manager. Anyone
    who managed a system where every account was privileged and kept
    it running as well as you did could never be considered lazy.
    
    The disconnect sounds like a good alternative to me. It solves the
    corruption problem and saves the context of the process, which in
    most cases seems to be important.
    
    re .12:
    
    If you have an employee who is very valuable to the organization
    but is often forgetful or easily distracted, do you suggest that
    you threaten to and/or fire them because they "forgot" to secure
    their terminal or release the terminal resource in a resource poor
    environment? 
    
    It seems to me that you can come up with an idle process killer that
    does all the "right" things. There are a couple that sound like they
    are pretty close already. 
    
    Sometimes a technical solution to a management problem is the solution
    with the minimum of impact and the maximum effectiveness. Different
    work environments and people require different solutions to the
    same problem.
    

    re .various:
    I know how easy it is thwart an idle process killer. I've done it.
    I know how frustrating is can be to have process blown away because
    you took too long to get a soda. 
    
    I need a solution to this problem that can be implemented with a
    minimum of frustration and ER problems. Maybe having the idle process
    killer just target the known problems would be a better solution.
    Assume that people will do the right thing until they don't. 
    
    Whaddaya think?
    
    						Has3

	re 15. You could easily modify AUTOLOGOUT (avalible from the 
toolshed) to send you a daily log. It currently keeps a log file of 
all users logged out. The last time I looked the sources were also
avalible in the toolshed. 
	AUTOLOGOUT has many other useful features like the ability
to designate certian users or images never to logout, or to designate
certian images to always logout(so much for trying to fool it). 

							Dennis

    
    re: .-2, .-3
    
    	Couldn't one of the various performance analyzers provide you
    with a report on process "resource consumption" (or lack of
    consumption) at particular intervals? 
    
    	It sounds like ACCOUNTNG.DAT could provide historical evidence
    for a particular system, too. 
    
    	We use VPA for instance. It collects tons of data, and since
    it does snapshot the system, it can give you some indication of
    what hogs are on the system - by knowing hogs you can get the
    "misers"... Although it pains me to think that you would end up
    penalizing processes which are not wasting anything except access,
    and quite possibly LAT-locked terminals or sessions......! 
    
    /pjh_who_also_hates_spirits

    RE: .16
    
>    Nestor, I never considered you to be a lazy system manager. Anyone
>    who managed a system where every account was privileged and kept
>    it running as well as you did could never be considered lazy.
    
    My comment about "lazy system management" was not directed at you
    Harry, but rather at some of the replies which implied that a lazy
    system manager used the idle process killers (no, I didn't take
    it personally Jon, just wanted you to be aware that many aren't
    lazy ;^)  Enough of that...
    
    As Jon, Harry, and everyone else realizes these tools can be bypassed,
    as many have already aluded to.  This simply constitutes
    "one-upsmanship", which I find to be a waste of my time.  Therefore,
    the usefullness of idle process killers are strickly left to the 
    discretion of the system manager.  It is ultimately his decision.
    
    I would try and adress all issues with the people involved, and
    if you can resolve them without the Idle Process killer, fine, even
    GREAT!  If not, have fun...
    
    -- Nestor

    RE: < Note 519.14 by ERIS::CALLAS "Strange days, indeed." >

>    This includes disconnecting
>    a terminal. Even if you can do it in a supported, reliable way, you're
>    merely passing the buck. Once TTY_TIMEOUT expires, the process is going
>    to get killed, only this time by the terminal driver. 

    Jon, you are right.  TTY_TIMEOUT when expired will stop the process,
    however, if you set it to a large enough value (a quick check in
    SYSGEN, and some calculations show that if TTY_TIMEOUT is set to
    %X7FFFFFFF Seconds, a user can remain disconnected for 24855 days.
    That seems to be long enough for me!  The system will have to be
    taken down well before that for a PM, Software Upgrade, or whatever.
    
    Enough again...
    
    -- Nestor

    re .20
    
>    Jon, you are right.  TTY_TIMEOUT when expired will stop the process,
>    however, if you set it to a large enough value (a quick check in
>    SYSGEN, and some calculations show that if TTY_TIMEOUT is set to
>    %X7FFFFFFF Seconds, a user can remain disconnected for 24855 days.
>    That seems to be long enough for me!  The system will have to be
>    taken down well before that for a PM, Software Upgrade, or whatever.
 
    yea, you could do that, but then wouldn't you get all these
    disconected processes hanging around forever? Or at least until
    the user logged in again, and got rid of them.  worst case: soemone
    in a hurry to start their three weeks of vacation forgets to log
    out... system doesn't crash/need rebooting for three weeks (haa haa
    haa), disconnected process never goes away...
    
    get enough of these, then what ???? (or did I miss something foolish,
    like usual ??)
    
    rocko 

    A detached process takes no cpu time, just memory and swap/page
    file space. If memory becomes tight, then they will be swapped out,
    and then only take about 1k memory. Such a process takes a bit over
    100 disk blocks on disk if it is in DCL. I assume your users do
    not normally go on holiday in the middle of running a large CAD
    package.
    
    So, during the time that 1000 of your users go on holiday, you will
    need an extra megabyte of memory, and a quarter of an RA81. Budget
    now for next summer!

Let's step back a bit:  Spirit-like programs exist because of two perceived
problems:

	a) Need to free up resources (mainly, terminal lines);
	b) Security - the undesireability of leaving jobs around
		that random people can get at.

It has been adequately documented in this note (and elsewhere) that there are
substantial costs - from lost work, corrupted databases, and so on - associated
with the use of such programs.  Since there is a simple solution to (a) - buy
more of the resource you are short of - what we have is a simple cost tradeoff.
In most cases, if you look at ti this way - and factor in the additional costs
in moral, wasted time, jobs delayed and not done, and so on that inevitably
accompany insufficient resources - it's hard to reach any decision other than
"buy some more damn terminal ports"!

As for (b), again the problem needs to be looked at more closely.  The problem
is not the process itself - it's that the process (may) be accessible to people
walking by the terminal.  Since a disconnected process is NOT so accessible,
disconnection is just as good a solution as killing the process.  For reasons
already discussed, for this to work the timeout until the terminal driver
kills the process must be very long.

There's no supported way to force another terminal to disconnect, but it's not
that hard to do.  A program to do it has recently been distributed to
INFO-VAX.

An alternative, if it could be written, would be a privileged program that
took over the inactive terminal and demanded your password before releasing
it.  This would be marginally more convenient than having to connect back to
a disconnected process.

The problem is, how to do this.  There's certainly no supported way.  A program
with SHARE can easily enough hang a read on the terminal; the problem is that
there is almost certainly already a read pending.  Messy.  Easiest might be
to disconnect, grab the terminal, then reconnect when the password is typed.
(Of course, there should be a version of the program thta the user can run that
would immediately lock the terminal.  If the terminal was so locked, the
"Spirit" program would leave it alone.)

OK, there's a programming challenge for someone!

Now, if I could only get the damned terminal switch here changed so it wouldn't
drop the line whenever 15 minutes go by with no characters in either direction.
(Of course, I've got a little command file that simply types "alive" every 5
minutes....)
							-- Jerry

    re .23:
    
	There's no supported way to force another terminal to disconnect, but
	it's not that hard to do.  A program to do it has recently been
	distributed to INFO-VAX. 
    
    Jerry, will you please post that program here?
    
    	Jon

    RE .-1
    
    I just looked for the one I wrote a coupla years ago but it must've
    gotten lost in a move between machines (still have the image though).
    All it did was a disconnect QIO to the other terminal (to get the
    disconnect operation into the queue) and then JSB to the RTIMOUT
    routine pointed to in the class driver vector portion of the UCB
    to kill off the read in progress.  Worked like a champ!  I'll keep
    looking.
    
    -r

The following program, in Fortran, will disconnect you from your own terminal.
It should work on other peoples' terminals; I haven't tried it though.

      include '($iodef)'
c
      integer*2 mychan
      character mydev*40,esc*1
      integer iret,iosb(2),SYS$ASSIGN,SYS$QIOW
c
      data esc /'1b'x/
c
c  translate and assign terminal name
c
      call SYS$TRNLOG('TT',,mydev,,,)
      if(mydev(1:1).eq.esc) mydev=mydev(5:)
      call SYS$ASSIGN(mydev,mychan,,)
c
      iret=SYS$QIOW(,%VAL(mychan),
     &              %VAL(io$_setmode.or.io$m_tt_discon),
     &              iosb,,,,,,,,)
      if(.not.iret) write(6,1000) iret
      if(.not.iosb(1)) write(6,1100) iosb
      call EXIT
c
 1000 format(' $QIO status: ',z8.8)
 1100 format(' IOSB: ',z8.8,1x,z8.8)
      end

    It will work on other people's terminals if you have SHARE priv. 
    
    	Jon

    Did you ever put and <ESC>c in a mail file, mail it to someone with
    the subject saying "Type EXTRACT TT:"  Does a nice reset.
    -=*>Jason<*=-

	    Putting a ^S in the text is even better ...

RE: .-2

No, but I have EDT'd a LOGIN.COM or two with a SET PROMPT="<ESC>c"

re:  DISCONNECT
The DISCONNECT QIO has one major problem:  Like any  QIO, it's queued.  If there
is a READ active on the terminal - and there usually is - the DISCONNECT will
wait until the READ completes.  The INFOVAX program didn't use this mechanism;
instead, it went into kernel mode and called the TT class driver directly.

I didn't keep a copy and it's probably no longer on the system.  Jon, you
should be able to find a copy on STAR - INFOVAX feeds a file on there
somewhere.  Failing that, ask Forrest Kenny [sp?]; he helped out with the
program.
							-- Jerry

    re: .30
    
    It should be:
    
    $ WRITE SYS$OUTPUT "%FAT-L-ERROR% - Fatal error."
    $ WAIT 00:00:05
    <ESC>c
    [EOB]      
    

Back on the track folks... A couple of questions arise.

Where is the INFOVAX notes file, that used to be on STAR:: as recently as
a month ago? I just get a file not found message.

Is there any other modifier that will force the IO$M_TT_DISCON QIO in ahead
of the pending read if one exists?

I have heard more than once that disconnected process are hard to get swapped
out without the swapper butchering the rest of the system first. One customer
has set SWPOUTPGCNT up to reduce the impact of this, but it seems the swapper's
strategy is not really suited to this sort of thing; it doesn't think the
system is tight on memory, even though when the disconnected processes are
killed it goes much faster and pages less. It's a pity DORMANTWAIT doesn't
apply to LEF's as well as COM's.

Comments?

= Giles =
 End of note 

� Where is the INFOVAX notes file, that used to be on STAR:: as recently as
� a month ago? I just get a file not found message.
    
    It's still there but a new version of the file was started a couple of
    weeks ago so your unseen count is probably screwed up.

I dug around and managed to find the article:


30-JUL-1987 02:16:34.17,3347;000000000000
Return-Path: <@KL.SRI.Com,@wiscvm.wisc.edu,@YMIR.BITNET:[email protected]>
Received: from yale-eli.arpa by yale-venus.ARPA ; 30 Jul 87 01:58:10 EST
Received: from KL.SRI.Com by yale-eli.arpa; Thu, 30 Jul 87 01:42:52 EDT
Full-Name: 
Message-Id: <[email protected]>
Received: from wiscvm.wisc.edu by KL.SRI.COM with TCP; Tue 28 Jul 87 02:36:20-PD
Received: from YMIR.BITNET by wiscvm.wisc.edu ; Tue, 28 Jul 87 04:34:24 CDT
Received: from ENGVAX.SCG.HAC.COM by YMIR.BITNET; Tue, 28 Jul 87 02:35 PDT
Date: Mon, 27 Jul 87 14:02 PDT
From: Kevin Carosso <[email protected]>
Subject: Disconnecting a virtual terminal
To: [email protected]
X-Vms-To: INFO-VAX-SUBMIT
 
> Sorry to bother the entire net with this, but CSNET couldn't/wouldn't
> recognize Kevin's address!
 
That's funny...  Historically, CSNET has been one of the few that DID
understand my address...
 
>  Could you clue me in on the CLASS_DISCONNECT you described?  I've
>  recently written such a beast, trying to DISCONNECT idle processes,
>  instead of blowing them away, but have had some problems.  I chose to
>  go to the fiche and "emulate" the DCL DISCONNECT command using the
>  IO$M_DISCON modifer.  This seemed to work just fine, EXCEPT, DCL has an
>  outstanding read request which must be cancelled, which I've done.  BUT
>  this TOO causes some problems, which we've learned to live with for the
>  time being.
 
Yes, there is a QIO SETMODE modifier that does a disconnect.  Unfortunately,
it gets queued behind any outstanding read QIO's that might already be on
the terminal.  An idle terminal nearly ALWAYS has a read sitting on it,
usually from DCL.
 
There is an entry point in the TT class driver that terminal port drivers
call when they need to "disconnect".  Note that "disconnect" in this context
is more general than you might think.  If a terminal cannot be disconnected,
the class driver will send a hangup, but it's all the same to the port driver,
it calls the same entry point.  This is what, for example, the DMF port driver
calls when modem signals indicate a phone line has hung up.  Or, it's what
I made the CMU pseudo-terminal driver do when the master process goes away
for some reason (if you TELNET and lose your network connection for example).
 
The code to do a disconnect basically figures out if the device in question is
valid, goes into kernel mode, finds the UCB for the terminal, gets the
physical UCB, gets the class/port interface base vector, and calls the
CLASS_DISCONNECT entry point -- thus doing the same thing the port driver
would've done if it thought it should.
 
I'm sending the code in a followup message to this one on the form of a
subroutine you can call.  Currently it checks that the device is disconnectable.
It needn't be, since it would still be a nice way to delete process' that
aren't on a disconnectable terminal.  They would get a hangup AST instead
of a DELPRC.  I didn't bother to remove the check since you'd still have
to make SOME check and not do anything if the terminal is an RT.
 
The code was originally a midnight hack by Forrest Kenney.  I modified it
somewhat.  I hope it doesn't crash your system, but I of course make absolutely
no guarantees.
 
        /Kevin Carosso                     [email protected]
         Hughes Aircraft Co.               kvc%[email protected]
 
30-JUL-1987 18:37:27.63,9318;000000000000
Return-Path: <@KL.SRI.Com,@wiscvm.wisc.edu,@YMIR.BITNET:[email protected]>
Received: from yale-eli.arpa by yale-venus.ARPA ; 30 Jul 87 18:35:31 EST
Received: from KL.SRI.Com by yale-eli.arpa; Thu, 30 Jul 87 18:16:37 EDT
Full-Name: 
Message-Id: <[email protected]>
Received: from wiscvm.wisc.edu by KL.SRI.COM with TCP; Tue 28 Jul 87 02:38:59-PD
Received: from YMIR.BITNET by wiscvm.wisc.edu ; Tue, 28 Jul 87 04:37:00 CDT
Received: from ENGVAX.SCG.HAC.COM by YMIR.BITNET; Tue, 28 Jul 87 02:36 PDT
Date: Mon, 27 Jul 87 14:07 PDT
From: Kevin Carosso <[email protected]>
Subject: code to DISCONNECT a terminal
To: [email protected]
X-Vms-To: INFO-VAX-SUBMIT
 
        .TITLE  UNLINK_VT a set of routines to unlike a VT
        .IDENT  /V1.0-000/
        .LIBRARY /SYS$LIBRARY:LIB.MLB/
 
;++
;
;               These routines are a system hack to allow a privileged user
;       to disconnect a VT with outstanding I/O from it's physical device.
;       The correct way to perform this would be to modify the code in TTDRIVER
;       that does the disconnect.  For testing purpose this is a more expediant
;       way to accomplist this goal.
;
;       NOTE:
;               The required privs to use this are:
;
;                       1) CMKRNL
;                       2) SHARE
;
; CALLING SEQUENCE:
;
;       ret_stat = UNLINK_VT (device_name)
;
;       device_name     -       address of a string descriptor, the string must
;                               contain name of VT to be disconnected (ex VTA0:)
;
; AUTHOR:
;
;       Forrest A. Kenney       28-August-1986
;
; REVISION HISTORY:
;
;       Kevin Carosso           14-JUL-1987     Hughes Aircraft, SCG/CTC
;               Modified a bit for local use, don't bother with
;               the privilege checks, must have CMKRNL and SHARE only.
;               Raise to device IPL while mucking in the UCB as
;               Forrest Kenney suggested.
;
;               Clear R2 before calling IOC$SEARCH.  Since we now run
;               above IPL 2, we have to lock our kernel code into memory.
;
;--
 
 
 
 
 
 
 
 
 
        .SBTTL  External and local symbol definitions
 
;
; External symbols
;
 
        $CCBDEF                         ; Define CCB
        $DVIDEF                         ; Device information
        $IPLDEF                         ; Define various CPU IPL levels
        $JPIDEF                         ; Process information
        $SSDEF                          ; System status codes
        $UCBDEF                         ; Unit control block
        $TTYDEFS                        ; TTY specific definitions
        $TTYMACS                        ; Define terminal macros
        $TTYUCBDEF                      ; TTY UCB definitions
 
 
;+
; A simple macro to help build item list items
;-
        .MACRO  ITEM    LENGTH,CODE,BUFF_ADDR,RET_LEN=0
 
        .WORD           LENGTH
        .WORD           CODE
        .ADDRESS        BUFF_ADDR
        .ADDRESS        RET_LEN
 
        .ENDM   ITEM
 
 
 
 
 
 
 
 
 
        .SBTTL  Allocate local storage
 
 
        .PSECT  $DATA   LONG,NOEXE,RD,WRT
 
DEVNAM: .BLKB   64                      ; Block hold PHYDEV name
        DEVNAM_LEN = .-DEVNAM
DEVNAM_SIZ:                             ; Storage for length of PHYDEV name
        .LONG   0
 
DISC_FLAG:                              ; Is device disconnectable
        .LONG   0
 
CHANNEL:
        .WORD   0                       ; Channel number for assign
IOSB:   .BLKW   4                       ; IOSB for $GETDVI
 
DVILST: ITEM    DEVNAM_LEN,DVI$_TT_PHYDEVNAM,DEVNAM,DEVNAM_SIZ
        ITEM    4,DVI$_TT_DISCONNECT,DISC_FLAG
        .LONG   0
 
lock_range:                             ; For $LKWSET call
        .address        begin_lock
        .address        end_lock
 
 
 
 
 
 
 
 
 
 
        .PSECT  $CODE   LONG,PIC,NOWRT,RD,EXE,CON,REL,LCL,SHR
        .SBTTL  Validate device & request
;+
;
;               This routine will validate the device to be disconnected is a
;       virtual terminal and the the user has the correct privs to do it.  The
;       sequence is listed below:
;
;               1) Assign a channel to the device
;               2) Determine if device can be disconnected
;               3) Calls KERNEL mode routine (to get UCB address and disconnect
it)
;
;       INPUTS:
;               4(AP)   - Address of a descriptor containing device name
;
;       OUTPUT:
;               R0      - Status of operation
;
;                               SS$_IVDEVNAM
;                               SS$_NOPRIV
;                               any possible returns from $ASSIGN or $GETDVI
;
;-
 
        .ENTRY  UNLINK_VT,^M<>
 
;+
; Lock down our kernel mode, high IPL code.
;-
        $LKWSET_S       INADR = lock_range
        blbs    r0, 5$
        ret
;+
; Get a channel to work with
;-
5$:     CLRQ    -(SP)                   ; Default acmode & no mailbox
        MOVAW   CHANNEL,-(SP)           ; Address of word to hold channel #
        MOVL    4(AP),-(SP)             ; Address of device name string
        CALLS   #4,G^SYS$ASSIGN         ; Assign channel
        BLBS    R0,10$                  ; Success continue
        RET                             ; Failed return with reason
;+
; Now get the device information and make sure it can be disconnected,
; also make sure that don't try to disconnect an already disconnected device
;-
10$:    $GETDVIW_S      CHAN=CHANNEL,-  ; Get device information
                        ITMLST=DVILST,- ;
                        IOSB=IOSB       ;
        BLBS    R0,20$                  ; Setup ok continue
        PUSHL   R0                      ; Save error reason
        BRW     1000$                   ; Branch to exit code
20$:    BLBS    IOSB,30$                ; OK continue
        MOVZWL  IOSB,-(SP)              ; Store failure reason
        BRW     1000$                   ; Branch to exit code
30$:    BLBS    DISC_FLAG,40$           ; Device disconnectable cont
        MOVZWL  #SS$_IVDEVNAM,-(SP)     ; Inproper device for requested operatio
n
        BRW     1000$                   ; Branch to exit code
40$:    TSTL    DEVNAM_SIZ              ; See if got physical device name
        BNEQ    80$                     ; If zero length then already disconnect
ed
        MOVZWL  #SS$_NORMAL,-(SP)       ; Store failure reason
        BRW     1000$                   ; Branch to exit code
;+
; Now build arg list & call Kernel mode routine
;-
80$:    MOVL    AP,-(SP)                ; Store device argument list on stack
        MOVAL   KRNL_CODE,-(SP)         ; Store address of Kernel routine on sta
ck
        CALLS   #2,SYS$CMKRNL           ; Invoke kernel mode routine
        PUSHL   R0                      ; Save status reason
 
;+
; We have a channel to free before exiting
;-
1000$:  $DASSGN_S       CHAN=CHANNEL    ; Free channel
        BLBS    R0,1010$                ; Ok just exit with correct reason
        MOVL    R0,R1                   ; Save channel DASSGN error
        POPL    R0                      ; Get previous status code
        BLBC    R0,1020$                ; Use first error
        MOVL    R0,R1                   ; Use DASSGN error
        RET                             ; Return
1010$:  POPL    R0                      ; Restore reason
1020$:  RET                             ; Return to caller
 
;+
; This section of code needs to run at elevated IPL to prevent process
; deletion while owning I/O database MUTEX.  It also will use a backdoor
; hook into the TTDRIVER to UNLINK the VT.
;
;       Note:   R4 contains the current processes PCB address it is suppiled by
;               the change mode dispatcher.  It is needed by SCH$IOLOCKR &
;               SCH$IOUNLOCK
;
;-
begin_lock:
 
        .ENTRY  KRNL_CODE,^M<R3,R5>
        DSBINT  #IPL$_ASTDEL            ; Raise IPL to prevent process deletion
        JSB     G^SCH$IOLOCKR           ; Lock the I/O database for read access
        MOVL    4(AP),R1                ; Get device descriptor string address
        CLRL    R2                      ; No flags
        CLRL    R3                      ; No lock value block
        JSB     G^IOC$SEARCH            ; Now find the devices UCB
        CMPW    R0,#SS$_DEVALLOC        ; See if device allocated
        BEQL    10$                     ; If allocated proceeded
        BLBC    R0,30$                  ; If no device then exit
 
10$:    DSBINT  UCB$B_DIPL(R1)          ; Raise to device IPL
        MOVL    UCB$L_TL_PHYUCB(R1),R5  ; Get device's physical UCB address
        BEQL    20$                     ; Device already disconnected just exit
        PUSHL   R4                      ; Save PCB address
        MOVL    UCB$L_TT_CLASS(R5),R4   ; Get class dispatch table address
        JSB     @CLASS_DISCONNECT(R4)   ; Now call disconnect code
        POPL    R4                      ; Restore PCB address
20$:    ENBINT                          ; drop back down
        MOVZWL  #SS$_NORMAL,R0          ; Store success as exit reason
 
30$:    PUSHL   R0                      ; Save reason
        JSB     G^SCH$IOUNLOCK          ; Unlock I/O database
        POPL    R0                      ; Restore reason
        ENBINT                          ; Lower IPL back to calling level
        RET
;
; Lock down pages between "begin_lock" and here so we don't pagefault
; at high IPL
;
end_lock:
        .END