Conference bulova::decw_jan-89_to_nov-90

Someone correct me if I'm wrong;

I think an entry in sys$manager:DECW$SERVER_ACCESS_ALLOWED.DAT needs to be made
I'm not sure this is documented for customers though. The file is simple text
with one entry for "transport node user" mine looks something like this:
(with the Bang)

!----------------------------
! transport node user
!
* mynode *
* clusterboot1 Myusername
* clusterboot2 Myusername
!----------------------------



The only thing I do with it is start the moon program when my system boots, but
it should work for your customer...

    RE .1 Can someone point me to where this is documented, or at least to a file
    format?
    
    Thanks,
    
    ken

The reason that what the customer is trying to do does not work is because
customize security is on a per user basis.  If there is no user, there is
no special security available.  It will allow only (local) SYSTEM to connect.

Now as to this file, it is NOT SUPPORTED.  It may disappear in a future
version.  If you really want to use it, the format is just as specified
in the previous note.

A supported way of doing this would be to write a program like XHost from
the MIT distribution which would have to be run in SYSTARTUP or some such.
It would have to send an XSetHost request to set the host list to the value
you desire.  Unfortunately, you can't set security with Username granularity
in a supported way with this method.  However, you can enable all incoming
connections from a particular node.  You can also turn off security
entirely (not recommended).

Burns

    OK, I'm a little slow, so let's see if I have this right:
    
    1.  Unsupported, but should work for time being is to entire something
    into the DECW$SERVER_ACCESS_ALLOWED.DAT file.
    
    2. Implementing some sort of customized XHOST program may do the job be
    allowing anyone from a particular node to run a program on the
    workstation, but can't limit access to a single user.
    
    3. There is no true supported, easy to use mechanism for this.
    
    Now, new questions:
    
    1. I've tried deciphering the file in .1 and have created something
    like this:
    !----------------------------
    ! transport node user
    !
    * fegpx *
    * clusterboot1 berkun
    * clusterboot2 berkun
    !----------------------------
    
    I'm not at all sure this is right and what "clusterboot" means or what
    I'm doing, or anything, but it doesn't allow me to run a little test.
    
    The test is: I've set up a file called test.com that runs the
    calculator.  The test file is on my workstation, fegpx.  On a host I
    type: submit/remote fegpx"access control"::test
    
    It dies with the error:
    
    :X Toolkit Error: Can't Open display
    %DWT-F-DWTABORT, xtoolkit fatal error
     
    I believe this test is a fair analog of what the customer is trying to
    accomplish.
    
    What am I doing wrong?  I'm willing to believe I'm missing something
    obvious in the file format...
    
    2. Does anyone anticipate a supported way of doing this?  It seems like
    a reasonable request and, btw, the customer is currently doing this
    under UIS.
    
    Thanks again,
    
    Ken B.
    
    
    

    I've heard that you must put all entries in UPPERCASE, so try
    
    	* FEGPX *
    
    and see if that fixes the problem.
    
    Mark

    re .5  Nope, that doesn't do it.
    
    But I wonder if I'm chasing the same problem as my base note, because
    I'm getting an X error, not a security error.
    
    And, BTW, what does "clusterboot1 and clusterboot2" mean?
    
    ken b
    
    
    
    
                      

re .-1

>    And, BTW, what does "clusterboot1 and clusterboot2" mean?

I'd guess that it's meant to be the name(s) of the boot node(s) in the cluster.

/Harley

  The format of the file is:

  <transport> <node> <user>

Where

  <transport> is either Local or Decnet
  <node> is the name of the node requesting access to the server
  <user> is the username of the person requesting access to the server


This file is not case sensitive...or at least is isn't on my system.


					-=> Jim <=-

    "I've heard that you must put all entries in UPPERCASE, so try"

    Jim's right, case doesn't matter.

    Thanks for all the help.
    
    Now, regardless of the contents of the file, I can do what I want for 
    SYSTEM but not for any other user.  For system it dies with an xlib
    error (something about i/o connections, I forget just what).
    
    If I read .3 right, I may be stuck.
    
    So final question:  Can someone come up with a way (or am I doing
    something blatently wrong) to allow me to run a job on the workstation
    on a user other than system when no one is logged on on the workstation
    itself?
    
    The simplest way to test is to log on remotely and set/display and run
    the calculator or clock.  I repeat, this works for system but not for
    joe user.
    
    Thanks again,
    
    Ken B.
    
    BTW, just out of curiosity, does anyone know when the ...access..dat
    file is read - at boot, login (wouldn't make sense) or at time of
    attempted access (makes most sense to me)?
    

 Do the following:

  Create a file that has the following (or substitute the right info)

  * HGOVC KENBERKUN

        or

  * * KENBERKUN

The file name should be DECW$SERVER_ACCESS_ALLOWED.DAT.

Create another file with nothing in it...(for future use)

The file name should be DECW$SERVER_ACCESS_TRUSTED.DAT.

Put these files somewhere, say, SYS$LIBRARY:.

Define the following logicals...

  $ DEF/SYS/EXEC DECW$SERVER_ACCESS_ALLOWED -
    SYS$LIBRARY:DECW$SERVER_ACCESS_ALLOWED.DAT

  $ DEF/SYS/EXEC DECW$SERVER_ACCESS_TRUSTED -
    SYS$LIBRARY:DECW$SERVER_ACCESS_TRUSTED.DAT

Then stop the server with something like 

  $ STOP/ID=

Then do

  $ @SYS$MANAGER:DECW$STARTUP


I've noticed that the restart parameter does not read these files.  I've had
to stop and then start the server for these to take effect.  I know that the
above works because we do everyday at the customer site.

  As a side issue you can stop the login process.  This is usually the process
with a name of WSAx, where x is some number.

  Good luck.

						-=> Jim <=-

You don't have to restart the server.  It reads the file on RESET.  The
server resets when there is a transition from "some connections" to "no
connection", i.e. when the last connection goes away.  Thus logging out
will do it.  Or logging in and out.

Don't create the "trusted" file, please.  You should not put stuff in there
if you don't know what you are doing.  Anyone allowed into the server
via that file will be able to change the host list and allow anyone else
in too.  It is like giving someone SECURITY priv.

You should not need the logicals either.  I just put my file in
SYS$SPECIFIC:[sysmgr] for the workstation.  The person in .11 needs the
logicals because he has the files in the wrong directory.

The fact that SYSTEM can log in but no one else would seem to indicate that
the file is not being read.  I don't know why that would be unless it is
in the wrong location or named wrong (or protected, maybe?)

Make sure that your batch job has a display defined.  Somewhere in the
batch command file, you should have something like

$SET DISPL/CREATE/TRANS=LOCAL

Burns

>>    <<< Note 960.12 by DECWIN::FISHER "Burns Fisher 381-1466, ZKO3-4/W23" >>>
>>
>>You don't have to restart the server.  It reads the file on RESET.  The
>>server resets when there is a transition from "some connections" to "no
>>connection", i.e. when the last connection goes away.  Thus logging out
>>will do it.  Or logging in and out.

  I thought that this is the way it was supposed to work but it never has
  for us.  I will go back and try it some more.


>>Don't create the "trusted" file, please.  You should not put stuff in there
>>if you don't know what you are doing.  Anyone allowed into the server
>>via that file will be able to change the host list and allow anyone else
>>in too.  It is like giving someone SECURITY priv.

  ok...ok...ok...

>>You should not need the logicals either.  I just put my file in
>>SYS$SPECIFIC:[sysmgr] for the workstation.  The person in .11 needs the
>>logicals because he has the files in the wrong directory.

  All the previous doc that I could find, mainly notes files, never said
  what the RIGHT directory was.  And why is SYS$LIBRARY: the WRONG 
  directory anyway?


>>$SET DISPL/CREATE/TRANS=LOCAL

  Don't you also need the /NODE= qualifier?


					-=> Jim <=-

    OK, around about now I'm beginning to feel very stupid, but I still
    can't this thing to work.  Here are the particulars:
    
I've tried both logging out and restarting the server.
      
    Again, it works for system, but not for a regular user.

Here is a directory of the file:

$ dir/full sys$specific:decw$server_access_allowed.dat

Directory SYS$SPECIFIC:[SYSMGR]

DECW$SERVER_ACCESS_ALLOWED.DAT;6          File ID:  (2573,4,0)
Size:            1/3          Owner:    [SYSTEM]
Created:  21-JUN-1989 10:41:52.17
Revised:  22-JUN-1989 08:54:05.48 (4)
Expires:   <None specified>
Backup:    <No backup recorded>
File organization:  Sequential
File attributes:    Allocation: 3, Extend: 0, Global buffer count: 0
                    No version limit
Record format:      Variable length, maximum 29 bytes
Record attributes:  Carriage return carriage control
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWED, Group:RE, World:RE
Access Cntrl List:  None

And here is the file contents:


!----------------------------
! transport node user
!
* FEGPX BERKUN
* FEGPX SYSTEM
* FEGPX *
* HGOVC *
* HGOVC KENBERKUN
* HGOV04 *
* HGOV04 KENBERKUN
!----------------------------

Note that I've tried quite a number of combinations of nodes and 
users...

FEGPX is the workstation
BERKUN is the workstation non-priv user
HGOVC is my cluster
HGOV04 is a specific node in the cluster
KENBERKUN is the user on the cluster that is attempting to use the 
workstation 


Here is the com file I submit:

$set display/create/transport=local/node=fegpx
$run sys$system:decw$calc

HELP!
    
    ken b
    

    Darn, have I got you all completely stumped? (I've got me stumped!)
    
    ken

Have you tried 0 for Node Name in decw$server_access_allowed.dat?
Maybe it's doing something special for local nodes and/or SCSNODE isn't
defined right.

Will other priv'd users work besides SYSTEM?  Maybe it's connecting fine
but ACCVIO'ing on a missing VMS priv?

Hoping that helps,

            == ken miller ==

    RE .16:  Thanks!  That did the job.  I stuck in 0 for the node name and
    it worked.
    
    Many thanks to all of you for your patience and perserverance.
    
    ken b.