From: jmacdonald@mta.ca
Subject: RE: Setting personal file service protection.
Reply-To: jmacdonald@mta.ca
Organization: Mount Allison U, Sackville, N.B. Canada 
Date: Wed, 7 Oct 1992 14:27:42 GMT

In article <009616F2.31976320.32464@okra.millsaps.edu>, nallegk@OKRA.MILLSAPS.EDU (Nalley, Gary K.) writes:
>> I was wondering if it is possible to change the default RMS protection of
>> personal file services (i.e. the M:\ directory ).
>>

... stuff omittexd... 

> 
>Hi, I've had the same problem and here is what DSN sent me.
> 
> 
>	+-------------------------------------------------------+
>	|   Gary. K Nalley	   Network Specialist           |
>	|   Computer Services      nallegk@okra.millsaps.edu    |
>	|   Millsaps College       nalley@decus.org             |
>	|   1701 N. State St.      Fax:    601.974.1168         |
>	|   Jackson, MS 39210      Voice:  601.974.1140		|
>	+-------------------------------------------------------+
> 
>-----------------------------------------------------------------------------
> 
>Sounds like you've encountered the "impersonal service" connection.
>It doesn't alleviate your immediate problem, but we have elevated the
>situation to Pathworks Engineering...the ability for *me* to connect
>to *your* personal service isn't what I expected from the PCFS_SERVER.
>I asked them to eliminate the capability entirely, or to make it
>dependent on the setting of the captive flag...as far as I know,
>there hasn't been a commitment on how they will address it.
> 
>On the brighter side, the ability to control the protection mask of
>files is something they have been addressing.  I know for sure that
>the functionality you are asking about has been put into the PW4VMS
>s4.1-1a kit.  It allows you to specify the protection mask to be
>associated with any file created under a VMS user account "personal
>service".  (For "defined" services, there are other mechanisms...)
> 
>I am currently trying to determine if the same functionality is
>present in the PW4VMS s4.1c kit, which would be the next logical
>step for your s4.1a server.  My understanding was that the 4.1c and
>4.1-1a kits were the same except for token-ring capabilities...but I
>cannot find reference to the protection mask control capability in
>the 4.1c documentation.  (It *is* in the docuemntation for the 4.1-1a
>kit, but the 4.1c kit doesn't mention it.)
> 
>I have checked around, and it appears that the ability to set a
>site-specific "default" protection mask *is* part of the 4.1c kit.
> 
>You should be able to pull the kit over DSNlink, using the DSN VTX
>application.  Instructions on how to set it up are in the release
>notes, section 7.4.  (I don't know how I missed it the first time.)
> 
>In the meantime - You should be able to eliminate the "impersonal
>service" connections by changing the protection masks on the .DIR
>files themselves.  (Changing all the files would tend to become
>rather tedious...)  Since the "username/service" connection is based
>primarily on the protection masks, if you changed the top level
>of the user's directory structure to disallow access at the GROUP
>level, attempts to connect to the account by another VMS user would
>be rejected.  (Thus:)
> 

To add my two cents worth.... I haven't tested this out using the group mask
but the world mask and I think the case is parallel.  Take an ordinary user
account "jdoe".  Say jdoe.dir does not have any WORLD access.  Say IN the jdoe
account (disk:[jdoe]reports.dir) there is a sub-directory WITH world access -
(WORLD:RE).  If another user tries to connect to the jdoe account in the
following manner, he/she can't because jdoe.dir has no WORLD access:

C:\> use m:\\server\jdoe%user-account *

BUT IF this user enters:

C:\>use m:\\server\disk:[jdoe.reports]%user-account *

they will get connected to THAT directory.  I was surprised by this.  This
ability to by-pass directory protection applies to directories in general - not
just to accounts.  I have talked to DEC - they indicated that in the future PW
might be configurable to limit file service connections to registered and
personal file services - and then all directories in general would not be
effected by this - but I guess the above example would still be possible. 
Something to be aware of.

>  If "SMITH" has a "home" directory of USER$DISK:[SMITH], change the mask:
>  $ SET FILE/PROT=(G) USER$DISK:[000000]SMITH.DIR
>  Then, user JONES would *NOT* be able to do the PC command:
>  C:\> USE ?: \\vaxname\SMITH%JONES *



Jane MacDonald  (jmacdonald@mta.ca)
Systems Programmer
Computing Services
Mount Allison University
Scakville, New Brunswick
Canada					.... standard disclaimers apply ...

Newsgroups: vmsnet.networks.desktop.pathworks