Sharing Files in a Network

Discourage users from sharing passwords and changing file and directory protection codes to grant the world category read or execute access. Grant BYPASS or READALL privilege cautiously.

The easiest way to share files on an occasional basis in a network environment is through the Mail utility. You mail the file to the intended recipient; there is no exposure of passwords, and the file is not made accessible to other users. However, there is the disadvantage of having to ask the file owner and wait for their response every time you want access. For an ongoing activity involving frequent access to shared files, it is better to set up proxy accounts and ACLs on the directories and files.

Using the Mail Utility

The easiest way for a user to transfer a text file to another user is to invoke the Mail utility (MAIL) and to send the user a copy of the file. This method is reasonably secure, because passwords need not be revealed and the original protection of the file is not changed. The receiving user simply includes a new file name with the MAIL command EXTRACT/NOHEADER to place a copy in the user's own directory. The copy automatically acquires the user's default protection. The user then uses the MAIL command DELETE to remove the copy from the mail file.

Setting Up Accounts for Local and Remote Users

A network manager may need to admit a number of users from outside nodes into a directory on the local node for a specific task. Therefore, you create a proxy account and add the proxy access to admit the outsiders into that one account (see “Procedure for Creating a Proxy Account”). If there are local users who need to share the files in this account's directory, then you provide that access and protect the files from outsiders by placing ACLs on the directory and files.

Consider a situation where a corporation needs a central repository for sales update information that is accessible to employees throughout the corporation.

The security administrator at the node where the files will reside (BNORD) creates the special account SALES_READER. The SALES_READER account is set up as a captive account with mail disabled. The default directory is [SALESINFO], which has the following default protection code:
(S:RWED,O:RWED,G:R,W)
Note that this protection code permits users in the same group as SALES_READER on the home node BNORD to read the files. Furthermore, only the users in the system category or the owner category, or those who have privileges that give them such access, can update the files in the directory. ACLs are used to further define the access, as described in step 3.
The security administrator uses the AUTHORIZE command ADD/PROXY to add the proxy access for the outside users. For example, to extend proxy access to user Jackson on node DEXTER and user Goodwin on node BANGOR, the commands would be as follows:
UAF>ADD/PROXY DEXTER::JACKSON SALES_READER/DEFAULT UAF>ADD/PROXY BANGOR::GOODWIN SALES_READER/DEFAULT

If later it becomes clear that other users at the home node BNORD need access and they do not belong to the same group as SALES_READER, ACLs could be added to the files in the directory [SALESINFO]. For example, suppose R. Grant needs control access to all the files and J. Martinez needs read access to all the files. The following two DCL commands would define the ACL for the directory and then propagate it to all existing files:

$ SET SECURITY/ACL=-
_$ ((IDENTIFIER=R_GRANT,ACCESS=CONTROL),-
_$ (IDENTIFIER=J_MARTINEZ,ACCESS=READ))-
_$ ((IDENTIFIER=R_GRANT,OPTIONS=DEFAULT,ACCESS=CONTROL),-
_$ (IDENTIFIER=J_MARTINEZ,OPTIONS=DEFAULT,ACCESS=READ))-
_$ [000000]SALESINFO.DIR
$ SET SECURITY/DEFAULT *.*;*

Admitting Remote Users to Multiple Accounts

When a small number of outside users need access, for differing reasons, to files requiring special protection, set up access to multiple proxy accounts, and apply extensive ACLs.

For example, a large corporation with many branch offices might choose to establish several proxy accounts for specific file-sharing purposes. Assume the central office wants to grant two key users from its two nodes in the eastern region read and write access to the project files for code name LEVIGRAY and read-only access to the BETSEYHARLOW project files. At the same time, there are three users from the western region who need read access to those LEVIGRAY files and require read and write access to the BETSEYHARLOW files. Only two users from the central office will have full access rights to the LEVIGRAY files, and two other users from headquarters will have full access rights to the BETSEYHARLOW files. For working purposes, the situation could be represented in tabular form, as shown in “Protected File Sharing in a Network”.

Example 13-4 Protected File Sharing in a Network

             Access Requirements to CENTRL::PROJ:[DESGN_PROJECTS]
                       Owned by [DESIGNERS,MGR]
Users & Nodes
                  Subdirectory LEVI         Subdirectory BETSEY
                    Project Files             Project Files
                     LEVIGRAY*.*              BETSEYHARLOW*.*

FRISCO::ALBION            R                        RW
FRISCO::ELTON             R                        RW
LA::IRVING                R                        RW
CENTRL::DIANTHA          RWED                     NONE
CENTRL::BRITTANIA        RWED                     NONE
CENTRL::ALBERT           NONE                     RWED
CENTRL::DELIA            NONE                     RWED
BOS::AYLMER               RW                       R
WASH::LAVINA              RW                       R

The following solution uses five proxy accounts in addition to the four local accounts on node CENTRL, plus ACLs on the directory, subdirectories, and files:

The security administrator at headquarters uses AUTHORIZE to create new proxy accounts on node CENTRL for the remote users Albion, Elton, Irving, Aylmer, and Lavina. These accounts should be captive, disallow mail, and be restricted to network access only. The accounts are even restricted to a subset of DCL through CLI tables. The default directory should be [DESGN_PROJECTS] for each user. The manager decides it makes sense to put them into the DESIGNERS group to match their proposed uses of the files.
Presumably, accounts already exist for users Diantha, Brittania, Albert, and Delia. They need not necessarily belong to the same group. They will be informed which device and directory to use for their work.

The next step is to add the proxy records to the network proxy authorization file with the following AUTHORIZE commands:

UAF>ADD/PROXY FRISCO::ALBION ALBION/DEFAULT
UAF>ADD/PROXY FRISCO::ELTON ELTON/DEFAULT
UAF>ADD/PROXY LA::IRVING IRVING/DEFAULT
UAF>ADD/PROXY BOS::AYLMER AYLMER/DEFAULT
UAF>ADD/PROXY WASH::LAVINA LAVINA/DEFAULT

The security administrator at node CENTRL places an ACL on the top-level directory for [DESGN_PROJECTS] with the following DCL command:
$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O,G,W) - _$ [000000]DESGN_PROJECTS.DIR
This ensures that no one outside of the system category of users can gain any UIC-based access to the files in the directory or any of the subdirectories unless they possess the BYPASS privilege. In fact, this restriction applies to those five users in the group DESIGNERS as well. The plan is for all files to possess ACLs that will admit the select group of users. It is desirable to propagate this protection code to all the files in this directory and its subdirectories. (The ACLs that will be placed on the files for further protection will take precedence when one of these users actually seeks access to a file.)
Two subdirectories are created in [DESGN_PROJECTS]:
- [DESGN_PROJECTS.LEVI]
- [DESGN_PROJECTS.BETSEY]

The security administrator uses the ACL editor to place the following additional ACEs in the ACL for the top-level directory:

DESGN_PROJECTS.DIR

(IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
(IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
(IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=EXECUTE)
(IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
(IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACESS=EXECUTE)
(IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
(IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=EXECUTE)
(IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=EXECUTE)
(IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=EXECUTE)

These protected ACEs ensure that only the select nine users can access the top-level directory. Because no one receives write or delete access to the top directory through the ACL, the directory and subdirectories are generally protected from deletion and renaming of files. (Of course, the system category of user obtains write and delete access through the UIC-based protection.)

Next, the security administrator creates ACLs on the subdirectories. The ACEs that are required are shown for their respective subdirectories:

[DESGN_PROJECTS]LEVI.DIR

(IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
(IDENTIFIER=DIANTHA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE
    +DELETE+CONTROL)
(IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
(IDENTIFIER=BRITTANIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE
    +DELETE+CONTROL)
(IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ)
(IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
(IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ)
(IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
(IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ)
(IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)

[DESGN_PROJECTS]BETSEY.DIR

(IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
(IDENTIFIER=ALBERT,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE
    +DELETE+CONTROL)
(IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
(IDENTIFIER=DELIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE
    +DELETE+CONTROL)
(IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
(IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ)
(IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
(IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ)
(IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)

Note that both preceding ACLs include two ACEs for each identifier. The first ACE controls the access to the subdirectory. It denies delete access for the protection of the subdirectory and is not propagated to all the files created in the subdirectory. The second ACE for each identifier will automatically propagate to all files added to its respective subdirectories because of the inclusion of the Default attribute. Furthermore, the Protected attribute ensures that all the ACEs are protected from deletion except by specific action.

At this point, all the groundwork has been completed. Over time, files are added to the subdirectories. Thus, when the user Lavina in Washington enters the following DCL command, the file LEVIGRAYMEM3.MEM is printed at node WASH:

$ COPY CENTRL::LEVIGRAYMEM3.MEM LP:

However, if user Lavina tries to edit this file, the attempt fails because user Lavina is denied write access through the ACL.

If there were many users involved in this scheme, it would soon become worthwhile to grant additional identifiers to the users. For example, each user that would be allowed read access to the files in the LEVI subdirectory might be given the identifier LEVI_READER, and so forth. The ACLs could then be shortened.