The GUARDFILE utility creates a guard file but does not attach it to a disk file or tape volume. You can attach to your disk file or tape volume a guard file that you own under your usercode, a guard file owned by another usercode, or a new guard file. If the attached guard file belongs to some other user, you allow that user to affect the access rights to your file.
For example, suppose you have attached a guard file owned by another usercode to your disk file and in the future the guard file owner defines access rights for a new user. The new user will have access to your disk file, even though you attached the guard file before the new user's access rights were defined.
For the rest of this discussion, the disk file, tape volume, or database to be guarded is referred to as the “object” of the guard file.
File Search Rules for Attaching Guard Files
You can create the guard file either before or after it is attached to an object. At the time of attachment, the system searches for the guard file title according to the normal file search rules. If necessary, the system applies family substitution in its search for a guard file. If there is no default family for substitution, the system applies the family name DISK by default.
If the guard file title is not prefixed by an asterisk (*) or a usercode, the system searches the usercode directory of the user making the request. If the guard file is not found there, the system searches the system (*) directory.
If the specified guard file is not available (either it is not visible to the user or it does not exist), the system still attaches the specified title with appropriate family substitution as the guard for the object and issues the following:
WARNING: <guard file title>: GUARDFILE NOT AVAILABLE
Consider the following example where the family statement is in effect for this process. The family statement is as follows:
FAMILY DISK = TEST1 OTHERWISE DISK
In addition, the following guard file is not available -- does not exist or is not visible to the user.
(USER)MY/GUARD/FILE ON TEST1
The following statement causes a message to be displayed:
SECURITY DATA/FILE GUARDED MY/GUARD/FILE
The message displayed is as follows:
WARNING: (USER)MYGUARD/FILE ON TEST1 : GUARDFILE NOT AVAILABLE PK72 (USER)DATA/FILE SECURITY CHANGED ON TEST1
Note that the family substitution was invoked and that the file DATA/FILE is now guarded by:
(USER)MY/GUARD/FILE ON TEST1
In WFL, family substitution is always invoked even if the target family—in this case, DISK—is specified in the guard file title. The following example has the same effect as the previous example:
SECURITY DATA/FILE GUARDED MY/GUARD/FILE ON DISK
CANDE uses family substitution if the ON clause is not specified but, unlike WFL, it ignores family substitution if the guard file title is qualified with a family name. So in the example, a guard file title of MY/GUARD/FILE ON DISK is assigned regardless of the family statement.
When you assign a guard file, the system ensures that the guard file name is qualified with a USERCODE and a FAMILYNAME.
If the system finds the specified guard file, but FILEKIND is not GUARDFILE, the system issues an error message and the old SECURITYGUARD value is retained.
Guard File System Checking at Access Time
Because the system stores the complete guard file title when the guard file is attached, the system does not apply family substitution or usercode inheritance to search for the guard file when a user or program attempts to access the guarded file. If the guard file does not exist or is not of FILEKIND GUARDFILE, the system treats the object as a private file (SECURITYTYPE = PRIVATE).
The system accesses the guard file regardless of the security attributes set on the guard file itself. The system has privileged status, which allows it to examine the contents of the guard file when required.
For more information about the SECURITYTYPE file attribute, see the MCP Security Overview and Implementation Guide.
Attaching Guard Files to Disk Files
You can use a CANDE SECURITY command, a WFL SECURITY statement, a program, or the MARC Changing DISK FILE Security screen to attach a guard file to a disk file.
As examples, you can use either of the following CANDE commands to attach a guard file to the disk file, MYFILE.
SECURITY MYFILE GUARDED MY/GUARD ON ADISK
SECURITY MYFILE CONTROLLED MY/GUARD ON ADISK
When you use the CANDE SECURITY command to attach a guard file, the action of attaching the guard file occurs when you transmit the command. If you do not specify a SECURITYGUARD value (MY/GUARD ON ADISK) in the preceding examples, CANDE responds with the following and the SECURITYTYPE value remains unchanged.
#INCOMPLETE STATEMENT
For more information about the CANDE SECURITY command refer to the CANDE Operations Reference Manual.
The following illustrates how you can use a WFL SECURITY statement to attach a guard file to a disk file.
WFL SECURITY MYFILE GUARDED MY/GUARD ON ADISK.
If you do not specify a SECURITYGUARD value in the preceding example, WFL responds with the following error message, and the SECURITYTYPE value remains unchanged.
ERROR: ILLEGAL FILE NAME
The WFL SECURITY statement attaches the guard file when the command is executed.
You can use WFL file equation statements to attach a guard file to a disk file. IN is the internal file name of the disk file to be guarded.
FILE IN(SECURITYTYPE=GUARDED, SECURITYGUARD=MY/GUARD ON ADISK) FILE IN(SECURITYTYPE=CONTROLLED, SECURITYGUARD=MY/GUARD ON ADISK)
When using file equations, the action of attaching the guard file occurs when you create the file—it does not affect existing permanent files.
You can use an ALGOL program to attach a guard file to a diskfile as in the following program:
100 BEGIN 200 FILE F (KIND=DISK, TITLE= " MYFILE ON ADISK." ); 300 OPEN (F); 400 F (SECURITYGUARD= "MY/GUARD ON ADISK." , 500 SECURITYTYPE=GUARDED); 600 END.
Note: | The SECURITYGUARD value must precede the SECURITYTYPE value. |
In the preceding program, If you do not specify
-
A SECURITYGUARD value and a SECURITYGUARD value was not specified in the past for MYFILE, the system responds with a warning, and the SECURITYTYPE value is changed to GUARDED without a value set for SECURITYGUARD.
WARNING: GUARDFILE IS NOT DEFINED @ (00000400)
-
A FILEKIND attribute value of GUARDFILE for the file MY/GUARD, the file MYFILE is not created and the following security error message is displayed:
MY/GUARD ON ADISK IS NOT GUARDFILE KIND FILE MYFILE OPEN ERROR: SECURITY ERROR @ (00000400)
Attaching Guard Files to Tape Volumes
If your installation supports guard file protection of tapes, you can use the WFL VOLUME CHANGE command to attach a guard file to a tape volume; if it does not, the system ignores the guard file. Refer to the security policy at your site to determine if your system supports guard file protection of tapes.
VOLUME CHANGE TAPEX (TAPE, SERIALNO=123456, SECURITYTYPE=GUARDED, SECURITYGUARD=MY/GUARD ON ADISK)
You can also use the WFL VOLUME ADD statement to attach a guard file to a tape volume if you are a privileged user, a SYSTEMUSER, or at an ODT.
Attaching Guard Files to Databases
You can attach a guard file to an entire database or to different parts of the database. Use the Data and Structure Definition Language (DASDL) features to do this. See the MCP Security Overview and Implementation Guide for information about attaching guard files to databases.