Granting Authority for Files and Directories
To share files using any of the three methods just mentioned, you first need to grant authority to other users to use a file or directory. Use the DMSGRANT routine (Grant Authority) to grant authority to other users.
- The issuer must own the file or directory to grant authority on it. The SFS administrator can also grant authority on any file or directory.
- If the issuer grants authority on an alias, the authority refers to the base file.
- An authority on a file in a file control directory does not imply that you have any authority on the directory in which the file resides.
- Authorizations cannot be granted on individual files within directory control directories or on aliases that refer to base files in directory control directories.
- READ or WRITE authority on a file control directory does not imply that you have any authority on any file within the directory. For example, READ authority on a file control directory allows another user to see the names of a file in the directory but not to read a file.
- Authority can be granted to a file in a file control directory even if the file is open or if the file or directory is locked, except when the file is locked exclusively by someone else.
To specify the name of the file or directory, use the actual identifiers or use namedefs. If you specify a file name or namedef for a file, you must also specify the directory in which it resides. If you omit the file name and file type or namedef for the file, then the name or namedef specified is assumed to be the directory to which authority is being granted.
Use the READ, WRITE, NEWREAD, NEWWRITE, DIRREAD, DIRWRITE, and READDIRREAD parameters in DMSGRANT to specify the type of authority being granted. For files in file control directories, you can grant READ and WRITE authority. For file control directories, you can grant READ, WRITE, NEWREAD, or NEWWRITE authority. For directory control directories you can grant DIRREAD and DIRWRITE authority. You cannot grant authority to individual files in directory control directories. For more information about these authorities, see the DMSGRANT routine description in z/VM: CMS Callable Services Reference.
All users must be authorized to communicate with an SFS file pool server. This may be done on an individual user basis or by specifying that anyone may communicate with it.
The file pool administrator controls authorization to an SFS file pool server. The file pool administrator allows anyone to communicate with an SFS server by issuing the ENROLL PUBLIC command. The file pool administrator allows an individual to communicate with an SFS server through the ENROLL USER command. ENROLL USER gives an individual a top directory. ENROLL PUBLIC and ENROLL USER allow a user to read or modify any file or directory for which he has those authorizations.
Additionally, the user may be authorized to use a specified amount of logical space in a particular SFS file pool or may not be allocated any space. The file pool administrator also does this through the ENROLL USER command on which the amount of space authorized can be specified. The space usage limit may be modified through the MODIFY USER command. This user may then create directories and files, and may authorize other users to use those files.
An alternative to using the DMSGRANT or DMSREVOK routines, is to use an external security program to determine who may read or modify your files.
An external security program may coexist with SFS base authorizations.
This means that if the program does not know about the object, SFS
authorizations are used. Optionally, an external security program
may be brought up to respond unauthorized
if it does not know
about the object.