Conference bulova::decw_jan-89_to_nov-90

No, there is not, just as there is not a LOGOUT.COM in regular VMS.

Burns

I've found that if I put the following in my DECW$LOGIN.COM, I can get a command
procedure to run when I quit my session:

	$ LOGOUT :== @SYS$LOGIN:DECW$LOGOUT

Then, in DECW$LOGOUT, you do the standard:

	$ DEL/SYM/GLO LOGOUT
	$ LOGOUT

    

    My customer, a military contractor, is migrating their engineers from
    VT's to VMS DECwindows workstations.

    Security rules require them to keep records of activity on classified
    files.  In the VT terminal environment they wrote a DCL procedure that
    would get this information from the engineer upon logout.

    The DECwindows environment poses a problem since it is now possible
    to kill DECterm windows, FileView windows, and the session without
    running the logout procedure.

    For the moment we can assume a standalone workstation with all
    applications executing locally.
    
    I think .-1 may satisfy them.  I tried it but with no success.  My
    DECW$LOGOUT.COM simply does not execute.

    Looking for help to find out why.

	Wouldn't file auditing using the Audit Server under VMS 5.2 and
	above cover this? It would probably be "more" secure than the
	current situation.

							mike

FWIW, "logging out" without going through logout is easy under any environment.

	paul

    
    Perhaps the audit server is more appropriate (I will suggest it) and
    logging out without going through logout is nothing new, but...
    
    What the customer is asking for is a way to run his logout procedure
    when a DECwindows workstation user stops his session.  A supported
    method of doing this is not required.
    
    I feel like we are close by using the suggestion in .2.  My first
    attempt failed because the VMS 5.3 DEC$STARTSM.COM procedure had been
    changed to do a STOP/ID=0 before the LOGOUT.  So now I redefined STOP
    also and DECW$LOGOUT.COM procedure runs.  (The customer realizes he may
    have to make changes with new releases and that's okay.  Of course he
    would much prefer a supported method of doing this.)
    
    Now the problem is that I cannot run a DECwindows program from
    DECW$LOGOUT.COM.  Here are my procedures:
    
    **** DECW$LOGIN.COM ****
    
        $! WRITE A FILE TO PROVE THIS WAS EXECUTED
	$ open/write f sys$login:decw$login.proof
	$ write f "from decw$login.com"
	$ close f 
	$ stop    :== stop/dont
	$ lo*gout :== @sys$login:decw$logout
    
    **** DECW$LOGOUT.COM ****
    
	$ set noon
	$ delete == "delete"
	$ delete/symbol/global logout
	$ open/write f sys$login:decw$logout.proof
	$ write f "from decw$logout.com"
	$ close f
	$ show display
	$ run decw$examples:helloworld
	$ logout
    	
    **** Here is the resultant DECW$SM.LOG ***
    
%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
 \DONT\

    Device:    WSA1:  [exec]
    Node:      0
    Transport: LOCAL
    Server:    0
    Screen:    0

XIO:  unable to open connection WSA1:
      after 0 requests (0 known processed) with 0 events remaining.
%XLIB-F-IOERROR, xlib io error
-DECW-E-CNXABORT, connection aborted
  UEBERSAX     logged out at 13-MAR-1990 13:57:02.19
    
    ****
    
    If I can find out how to get helloworld to run in decw$logout we're
    home free.  At least for now.  (I'm assuming we're going to have to put
    a DECwindows interface on the customer's logout procedure.  If there is
    a way to avoid this I'd like to know.)
    
    Thanks, Kris.

Well, it seems clear to me that, in fact, DECW$LOGOUT is being executed.  That
is where the SHOW DISPLAY output comes from.  It would also appear that
someone is executing "STOP", since you get the message about DONT from the
STOP/DONT which you put in there.

My guess would be that by the time DECW$LOGOUT is executed, the session manager
has changed the access privileges on the server such that only SYSTEM can write
to it.  That is why you can't open the display despite the fact that the
display exists.  Note also that by the time you get to this point, all the
applications connected to the server will have been disconnected by the session
manager.  To test this, try logining in as SYSTEM...bet it works.

I can't think of a real good, foolproof way around this.  If you had privs, you
could creprc a new process running as SYSTEM to do what you want.  You could
also create a DECW$ACCESS_ALLOWED.DAT file to always allow the user to connect,
but (1) that is not good for security, especially if you have multiple users
using the same workstation, and (2) as I think about it, I'm not sure that would
work...the session mgr may have set the access to SYSTEM explicitly rather
than via a server reset.

Burns

    
    The STOP is being run in DECW$STARTSM.COM after the session
    manager image exits.
    
    It occurred to me that putting a DECwindows interface on the customer's
    procdure would be nice but not really necessary.  If there is a way to:
    
    	- put the workstation in console mode
    	- run the procedure as if the workstation was a terminal
    	- return to DECwindows login screen
    
    I bet that would do the trick.  Possible?
    
    Thanks, Kris.

    
    I got some help from Bill Matthews offline and his suggestion followed
    Burns' in .7.  Burns was right; I tried it and it works.  I have
    attached Bill's message which states exactly what to do.
    
    It would certainly be better if we could run the procedure in console
    mode as I mentioned in .8.  I tried redirecting sys$input and
    sys$output to opa0: before running the procedure.
    
    With privs turned on this worked but chars input where not echoed on
    the screen.  I then tried it without privs with the protection  on
    opa0: set to w:rwe.  On a firefox running 5.3-1 this crashed VMS.
    
    Should I go to VMSNOTES for help using opa0:?
    
    Thanks.
    
    -------------------------------------------------------------------------

I just talked to the session manager developer. To run after a quit session
you must do a couple of things. One thing is to create a
decw$server_access_allowed.dat file that contains an entry for the session
manger, that is it allows access for the system account through the local
transport. The file contains lines of triplets of the form
transport-type node username for example * 0 SYSTEM must be in the file and
allows the SYSTEM account on the local node to connect to the server with any
transport. Two more examples are
LOCAL 0 BMATTHEWS
DECNET STAR BMATTHEWS

The first allows user BMATTHEWS to connect from the local system thru the LOCAL
transport, the second line allows user BMATTHEWS to connect from node STAR
through the decnet transport.

This file should be placed in sys$manager. It is used for access when the
session manager is not active and is how in fact the session manager and
loginout are allowed access to the server.

One other note. Well the server is resetting after a quit session it may deny
any connections for a period of several seconds. The session manager accounts
for this by retrying to connect to the server once every few seconds. Your
customers app will have to do the same thing.

						Hope this helps,
							Bill