From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX"  6-APR-1993 08:43:50.89
To:	INFO-VAX <INFO-VAX@KL.SRI.COM>
CC:	
Subj:	RE: protected terminals (was re: how can i keep somebody .

Hi,

Nowadays its not often that I'm prompted to contribute to Info-VAX (aka. Info-Glut)
but when something positivly dangerous/wrong is posted, I feel the urge to reply...

(this goes on a bit, sorry...)

In article <1ohggeINNgaf@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU writes...
> # 
> #If the executive-mode logical name SYS$SYLOGIN is defined in the system table,
> #that file will be executed before the file defined in the LGICMD field in your
> #SYSUAF entry or any file you specify via the /COMM qualifier to your username
> #at login.  Period.  To change this, you'd have to patch LOGINOUT.EXE (or the
> #terminal driver, forcing it to trigger something other than LOGINOUT).
> 
> Correction: It is the job controller (JOBCTL) which runs the LOGINOUT image.
> 	    That is what one would need to patch to run something else.
> 

Then Bill Laut (laut@alien.gici.com) wrote:

> Alternative:  Inside the Exec there's a couple of vectors labelled
> SYS$AR_JOBCTLMB and TTY$GL_JOBCTLMB.  These contain the UCB
> address of the mailbox that JOBCTL is receiving messages with.
> Instead of patching JOBCTL, an easier proposal might be:
> 1)  Create another permanent mailbox.
> 2)  Allocate a chunk of non-paged pool.
> 3)  Insert your terminal-checking code into the block.
> 4)  Put the UCB of your other mailbox into the
>     TTY$GL_JOBCTLMB longword.
> 5)  Allocate an IRP, dummy it up, and insert the
>     address of your SUBROUTINE (not procedure) into
>     the IRP$L_PID offset.
> 6)  Queue the IRP to the alternate mailbox.
> 7)  Have a beer.
> 
> Now, when the terminal class driver gets an unsolicited
> terminator from a terminal, it will create the usual MBX
> message and drop it into the mailbox at TTY$GL_JOBCTLMB,
> which now happens to be *your code*.
> 
> Check out the vitals in the mailbox message, and decide if
> this is a terminal you want protected.  If not, relay the
> message to the mailbox in SYS$AR_JOBCTLMB and let JOBCTL
> process it as usual.
> 
> If this is a protected terminal, then fire up the program
> you want to execute against that terminal.  Since you are
> currently running in system context, you obviously cannot
> issue a $QIO without incurring fatal results.  Instead, 
> scan the process table to locate JOBCTL, and then queue up
> a kernel-mode AST to the process, as follows:
> 
> 1)  Allocate a block of nonpaged pool for an ACB.
> 2)  Initialize it as a kernel-mode AST, with the
>     PROCEDURE (not subroutine) entry point being in
>     another part of your first pool block.
> 3)  Grab the SYNCH spinlock and increment the target
>     process' PCB$B_DPC counter.
> 4)  Fork down to IPL$_QUEUEAST
> 5)  Set the desired priority boost in R2.
> 6)  JSB   G^Sch$QAst
> 7)  Re-initialize the IRP for another read request.
> 8)  Synch with the Mailbox
> 9)  Requeue the IRP to the mailbox.
> 
> At this point, the thread is now running as a kernel-mode
> thread against JOBCTL.  The PCB$B_DPC increment prevents the
> process from being deleted until after the AST has finished.
> 
> We now pick it up within the AST:
> 
> 1)  Construct a character string, representing the
>     protected terminal's name.
> 2)  Invoke $CREPRC, passing the terminal name as
>     Input, Output, and error, as well as the image
>     you wish to have executed.
> 3)  Grab the SYNCH spinlock and decrement PCB$B_DPC.
> 4)  Release the spinlock.
> 5)  Stick SS$_NORMAL into R0 and issue RET.
> 
> You now have a detached process created against the protected
> terminal, running the image of your choosing.
> 
> Gull Island Consultants, Inc.	Phone:     (616) 780-3321
> Muskegon, MI  49440		>> "Usual disclaimers, apply within" <<> 

Gosh! Forgive me if I'm being a bit daft here, but I was taught that the
most things (even on VMS) can be done simply. Apart from anything else,
Bill's code above will not work on VMS V5.0 or later (and, for all its
complexity, on versions prior to that). The terminal class drive DOES NOT
USE TTY$GL_JOBCTLMB, it ONLY uses SYS$AR_JOBCTLMB. You MUST NOT UNDER ANY
CIRCUMSTANCES alter the vector in SYS$AR_JOBCTLMB because you will break