From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 13-JUN-1993 14:45:59.02
To:	EVERHART
CC:	
Subj:	Re: Stopping SET HOST to certain machines

From: jeh@cmkrnl.com
X-Newsgroups: comp.os.vms
Subject: Re: Stopping SET HOST to certain machines
Message-Id: <1993Jun10.114558.2156@cmkrnl.com>
Date: 10 Jun 93 11:45:58 PDT
Organization: Kernel Mode Systems, San Diego, CA
Lines: 107
To: Info-VAX@kl.sri.com
X-Gateway-Source-Info: USENET

In article <13188542@MVB.SAIC.COM>, "Wanted: Good used low-time TARDIS" <MORRIS@PATRICK-PIMS.AF.MIL> writes:
> Ok, here's the hardware setup:
> 
> (Maggie)        (Sam & Coach)
> 8350 ----- (2) VaxServer 3900s
>                   :
>          Several VaxStation 3100 m38 (Carla, Diane, Gary, Norm, Woody & others)
>          Several VT320s, Some of which are on the 3100s
> 
> Software: SecureVMS 5.4-2
> Sam and Coach are licensed to run all the layered products we have.  Some of
> the 3100s are and some are not.  Most of the 3100s have a VT320 on the serial
> port.  All 3100s have a limit of 2 logons.
> 
> Ok, here's the problem:
> We have one group of users who have 3100s that are not licensed to run some of
> the software so they should do a SET HOST to Sam or Coach.  Unfortantly they
> persist in doing SET HOST to other 3100s that can run the software.  

You didn't say whether this was all one cluster (with a common SYSUAF).  It
probably isn't.  If it is you could simply delete their usernames from the 
SYSUAFs on the appropriate machines.  

If it is a cluster, the solution is fairly simple.  There are several ways to
do it; all depend on DCL code in SYLOGIN.COM.  The following is the one I like
best because it does not require changing SYLOGIN more than once, regardless
of changes in user status, node names, etc.  

Let's suppose that DIANE is one of the machines they shouldn't SET HOST to. 
Create an identifer called DENY_INTERACTIVE_DIANE: 

	UAF> add/ident deny_interactive_diane

Then grant this identifier to each of the offending users:

	UAF> grant/ident deny_interactive_diane picard_j
	UAF> grant/ident deny_interactive_diane riker_w

Then place the following in the cluster-wide SYS$COMMON:[SYSMGR]:SYLOGIN.COM : 

	$ denyident = "DENY_" + f$mode() + f$getsyi("SCSNODE")
	$ useridents = f$getjpi(0,"process_rights")
	$ useridents_len = f$length(useridents)
	$ if f$locate(denyident,useridents) .le. useridents_len
	$ then
	$	write sys$output "You are not authorized to log into this node"
	$	logout
	$ endif

Note that this still allows network access (for DECnet file copies, sending
mail if that doesn't go through a default account, etc.). and batch access.
If this is not desired, add appropriate identifiers such as DENY_BATCH_DIANE,
and grant them to the appropriate lusers.  The SYLOGIN.COM need not be 
changed for any added nodes, usernames, or access types.  

Note also that there are several types of "interactive" login; this denies them
interactive access even if they walk over to a direct-connected terminal (one
of your VT320's) on the "denied" machine. You can extend the above message by
changing "INTERACTIVE" to "REMOTE" or "DIALUP" depending on the value of
f$getjpi(0,"JOBTYPE") , which returns: 

JPI$K_DETACHED         0
JPI$K_NETWORK          1
JPI$K_BATCH            2
JPI$K_LOCAL            3	(interactive - local terminal)
JPI$K_DIALUP           4	(interactive from dialup terminal)
JPI$K_REMOTE           5	(interactive from RTAn:, ie SET HOST)

(mode = INTERACTIVE is the union of jobtype = {LOCAL | DIALUP | REMOTE} )
there doesn't seem to be a lexical that will quickly return one of the 
strings LOCAL, DIALUP, or REMOTE, but the following will do:

$ jobtype = f$getjpi(0,"JOBTYPE")
$ jobtype_str = f$element(jobtype,"|","DETACHED|NETWORK|BATCH|LOCAL|DIALUP|REMOTE")

(this could be done in one line, but I broke it up for clarity)

So the preceding code might become

$ jobtype = f$getjpi(0,"JOBTYPE")
$ jobtype_str = f$element(jobtype,"|","DETACHED|NETWORK|BATCH|LOCAL|DIALUP|REMOTE")
$ denyident_all = "DENY_ALL_" + f$getsyi("SCSNODE")
$ denyident_mode = "DENY_" + f$mode() + f$getsyi("SCSNODE")
$ denyident_jobtype = "DENY_" + jobtype_str + f$getsyi("SCSNODE")
$ useridents = f$getjpi(0,"process_rights")
$ useridents_len = f$length(useridents)
$ if f$locate(denyident_mode,useridents) .le. useridents_len -
 .or. f$locate(denyident_jobtype,useridents) .le. useridents_len -
 .or. f$locate(denyident_all,useridents) .le. useridents_len
$ then
$	write sys$output "You are not authorized to log into this node"
$	logout
$ endif

Now you can grant someone DENY_INTERACTIVE_DIANE to keep them from logging 
into DIANE interactively from any "terminal", or DENY_REMOTE_DIANE if you
just want to block SET HOST access, or DENY_ALL_DIANE to prevent them from
running batch or network jobs there.  Since you can grant someone more than
one of these identifiers, combinations are possible -- grant them 
DENY_REMOTE_DIANE and DENY_NETWORK_DIANE to keep them from doing SET HOST 
or network operations, but they could still log in to a local terminal.

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com  Uucp: uunet!cmkrnl!jeh  CIS: 74140,2055

