[Info-vax] disabling a CTRL/Y ast

[Tom Adams]

On Thursday, January 7, 2016 at 2:37:41 PM UTC-5, VAXman- wrote:
> In article <878f843d-0a3e-4717-a02c-a0bf4f448be1 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
> >On Thursday, January 7, 2016 at 1:37:55 PM UTC-5, VAXman- wrote:
> >> In article <fd6d6c6a-1c7d-432d-ac2b-1244dfa0fbb6 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
> >> >On Thursday, January 7, 2016 at 11:21:27 AM UTC-5, VAXman- wrote:
> >> >> In article <3a583568-e33e-446e-9805-6ea94f9ebf71 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
> >> >> >On Wednesday, January 6, 2016 at 12:22:06 PM UTC-5, Stephen Hoffman wrote:
> >> >> >> On 2016-01-06 16:46:32 +0000, Tom Adams said:
> >> >> >> 
> >> >> >> > I want to turn ctrl/y into a noop in certain regions of code and turn 
> >> >> >> > ctrl/y into an exit in other regions of code.
> >> >> >> 
> >> >> >> Some background: I've posted more than a few replies here in the 
> >> >> >> comp.os.vms newsgroup, specifically discussing the particular 
> >> >> >> application in question and its general design, and an unfortunate 
> >> >> >> aggregation of the UI and the more critical code paths, and your 
> >> >> >> understandable preference to avoid restructuring the application code 
> >> >> >> through reworking the existing design to block ^Y from arriving within 
> >> >> >> the most critical sections of the code.
> >> >> >> 
> >> >> >> > I do find that it is necessary to run lib$disable_ctrl at the beginning 
> >> >> >> > of the program and lib$enable_ctrl at the end of the program to restore 
> >> >> >> > the previous CLI state, but I need to run asts to do the rest.
> >> >> >> 
> >> >> >> If you want ASTs in some parts of the code and not in others, then 
> >> >> >> you're going to have to wrap those sections appropriately.   That's if 
> >> >> >> you don't decide to migrate those critical code sections into another 
> >> >> >> process context, or related steps.  Because beyond the potential for ^Y 
> >> >> >> in these sections and the associated issues you're having with the 
> >> >> >> image rundown processing in the absence of an EXIT command, other sorts 
> >> >> >> of generic application failures ("bugs") or any arriving $forcex calls 
> >> >> >> or such activities can potentially still leave the application in an 
> >> >> >> indeterminate state.
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> -- 
> >> >> >> Pure Personal Opinion | HoffmanLabs LLC
> >> >> >
> >> >> >Here's an example of what I am trying to do that seems to work OK.
> >> >> >I guess a forced exit from a bug could leave the CTRL\Y in
> >> >> >the disabled state at the CLI instead of the original state.
> >> >> >
> >> >> >Also, it's possible that someone could define TT to be some terminal
> >> >> >other than the login terminal.  VMS leaves all the built-in process
> >> >> >logicals that refer to the login terminal vulnerable to redefinition.
> >> >> >It may be possible to roll your own safe (executive, no_alias) logical
> >> >> >name via a call in syslogin.
> >> >> >
> >> >> >Also, I still need to cover the cases where this code runs in a context
> >> >> >where TT is not defined.
> >> >> 
> >> >> 	PROGRAM MY_TERMINAL
> >> >> 	IMPLICIT NONE
> >> >> 
> >> >> 	INCLUDE '($DSCDEF)'
> >> >> 	INCLUDE '($JPIDEF)'
> >> >> 	INCLUDE '(LIB$ROUTINES)'
> >> >> 
> >> >> 	INTEGER*4 STATUS
> >> >> 
> >> >> 	RECORD	/DSCDEF1/ TERMINAL
> >> >> 
> >> >> 	TERMINAL.DSC$W_MAXSTRLEN = 0
> >> >> 	TERMINAL.DSC$B_DTYPE = DSC$K_DTYPE_T
> >> >> 	TERMINAL.DSC$B_CLASS = DSC$K_CLASS_D
> >> >> 	TERMINAL.DSC$A_POINTER = 0
> >> >> 
> >> >> 	STATUS = LIB$GETJPI(JPI$_TERMINAL,,,,TERMINAL,)
> >> >> 	IF (STATUS.AND.1) THEN
> >> >> 	  STATUS = LIB$PUT_OUTPUT(TERMINAL)
> >> >> 	ENDIF
> >> >> 
> >> >> 	CALL SYS$EXIT(%VAL(STATUS))
> >> >> 	END
> >> >> 
> >> >> -- 
> >> >> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
> >> >> 
> >> >> I speak to machines with the voice of humanity.
> >> >
> >> >That's better than TT.
> >> >
> >> >But that is also vulnerable to a non-priv user. For instance
> >> >if the login terminal is RTA1:  the a non-priv user can define RTA1
> >> >thusly:
> >> >
> >> >DEFINE RTA1 LTA180:
> >> >
> >> >Where lta180: is a valid device name.  Calls like SYS$ASSIGN will dutifully
> >> >translate RTA1: to LTA180: assign it a channel, and return a
> >> >normal status.
> >> >
> >> >Admittedly, it's not very likely that a non-priv user would do that.
> >> 
> >> Unless your nonprivied user as discovered a way to write PCB[PCB$T_TERMINAL],
> >> I doubt you'll have much to worry about. ;)
> >> 
> >Not sure what you mean?
> >
> >Do you mean that a non-priv user probably does not have alternative valid name
> >to use.  You are right about that.
> 
> I mean that your nonprivied user will not be able to alter the system memory
> where the terminal name is obtained by the SYS$GETJPI request.  I've used the
> LIB$ wrapper around SYS$GETJPI because I can pass a dynamic string descriptor
> to it and VMS will allocate some process memory into which it will write the 
> terminal name.
> 
> -- 
> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
> 
> I speak to machines with the voice of humanity.

OK, thanks.

The image I am working is installed with: cmkrnl,grpprv,sysprv,oper,security

Perhaps it could allocate memory, but I don't recall a specific case where it does.