File Protection

Each file on the system has an associated protection level. This controls who may use the file and in what ways. You may protect your files to allow or prevent other users from reading or modifying them. Keep in mind that the system manager and perhaps certain other users are able to override any protections you place on your files. This is a necessary feature; the system manager must be able to read your files in order to create backup copies to be used in the event of a disk failure or accidental deletion.

Please be aware that access to files is determined in part by protections placed on the directory containing the files in question. Directories may have the same types of protections placed on them as the files they contain. However, since it is possible to access files without using a directory, an expert user may be able to bypass directory protections in some circumstances. It remains important to protect files themselves, without relying totally on directory protections.

Files may be protected by two methods: UIC-based protection codes normally associated with every file created and optional access control lists (ACLs). ACLs provide finer-grained file protection than UIC-based protections and can allow or disallow access to individual users or holders of certain identifiers.

ACLs are used somewhat infrequently but, if present, are checked before normal UIC-based protections. Processing stops and access is granted as soon as an item is found that grants the requested type of access, even if a later item would have explicitly denied access.

ACLs are described after the discussion of UIC-based protection.

File Protection Bits

A set of protection settings is associated with every file. They control who may access the file for various kinds of operations. Accesses are broken down into four categories: read, write, execute, and delete. Users attempting access to a file are grouped into four categories: system, owner, group, and world. Each class of user may be allowed or disallowed each type of access. The classes of users are as follows:

System: Any entity running under a system User Identification Code (UIC). A system UIC is one whose group number is less than or equal to a changeable system setting called MAXSYSGROUP, whose default value is 10 (octal). The OpenVMS operating system itself, the system manager, system operators, and backup operators usually have UICs in this range.

OWNER: Any user whose UIC exactly matches the file owner. This is usually the creator of the file, but sometimes it is the owner of the directory in which the file resides or some other user.

GROUP: Any user whose UIC group number matches that of the file owner.

WORLD: This includes all system users.

When the requestor belongs to more than one of these categories, the most permissive match prevails.

The following are the types of access that may be granted to each class of user above:

READ: The ability to examine the contents of a file. If the file is a program or DCL command procedure, READ access also grants the ability to execute it.

WRITE: The ability to modify the contents of a file, append information to it, or create a new version. If you grant write access to a class of users, you should also grant read access. Otherwise, attempts to use DCL commands, such as EDIT, APPEND, OPEN /APPEND, or OPEN/WRITE, will fail.

EXECUTE: The ability to run a program or execute a DCL command procedure. With EXECUTE access alone, a user may execute a program or command procedure but may not TYPE, COPY, PRINT, or otherwise examine the file. When applied to a directory, EXECUTE access allow users to look up a file in the directory if they explicitly specify the file name.

DELETE: The ability to delete the file.

There is a fifth type of access, CONTROL, which is not included in the protection bits, but which is granted or denied automatically. CONTROL is the ability to change the protection codes of a file or directory. It is granted automatically to users in the SYSTEM and OWNER categories, but never to GROUP or WORLD users. Because CONTROL access allows changes to protections, SYSTEM users can always gain full control over the file, as can the OWNER. Control access can also be granted to others via an access control entry (ACE).

Examples of UIC-Based File Protections

When a file is created, it is generally created with the following protections:

• System: RWED

• Owner: RWED

• Group: RE

• World: none

The next few examples show how to change those default settings.

If you wanted to disallow anyone beside yourself access to a file SECURE.TXT, you would use this command:

    $ SET FILE/PROTECTION=(S:R,O:RWED,G,W) SECURE.TXT 

SYSTEM is still granted READ access so that backups may be performed on the file. Remember that a SYSTEM user can gain access to any file, but it would require an extra step. Therefore, disallowing SYSTEM access will not protect the file from SYSTEM users, but may cause it to be skipped during system backups. Generally, SYSTEM should be allowed at least READ access.

If you wanted to allow members of your UIC group to view and modify the file and any user to view it:

    $ SET FILE/PROTECTION=(S:R,O:RWED,G:RW,W:R) SECURE.TXT 

And if you wanted to allow full access to everyone:

    $ SET FILE/PROTECTION=(S:RWED,O:RWED,G:RWED,W:RWED) SECURE.TXT 

Please be aware that setting file protections on directory files does not necessarily protect the files in those directories. Under OpenVMS, it is possible to access a file directly without using a directory. You should protect the files themselves.

Access Control Lists

Access Control Lists (ACLs) supplement the standard UIC-based protection. ACLs grant or deny access to an object to holders of specific identifiers. If an object has an ACL, it is checked before the normal UIC-based protection mechanism.

An ACL is composed of one or more Access Control Entries (ACEs), which are evaluated in the order in which they appear. When an ACE that grants the requested access is found, processing stops at that point and access is granted. This is true even if a later ACE would have explicitly denied access. For this reason, you should place ACEs that deny access first.

You may add an ACE to a file with the following command:

    $ SET FILE filespec -      /ACL=(IDENTIFIER= ident_name,ACCESS=type_of_access) [/DELETE] 

The /DELETE qualifier deletes an existing ACE matching the one you specify.

Note that ident_name is the name of an identifier, which is a credential that can be heldby one or more users. You may also specify the username of individual users becauseOpenVMS creates a separate identifier for each user by default. For example, userMIKE holds the identifier MIKE, and user HERMAN holds the identifier HERMAN. Other identifiers, such as the hypothetical PAYROLL identifier discussed earlier, may be held by more than one user.

Example:

    $ DIRECTORY/ACL ZZZ.TXT    Directory DKA100:[LOGS]    ZZZ.TXT;1    Total of 1 file.    $ SET FILE ZZZ.TXT /ACL=(IDENTIFIER=MIKE,ACCESS=NONE)    $ SET FILE ZZZ.TXT /ACL=(IDENTIFIER=HERMAN,ACCESS=READ+WRITE)    $ DIRECTORY/ACL ZZZ.TXT    Directory DKA100:[LOGS]    ZZZ.TXT;1              (IDENTIFIER=[HERMAN],ACCESS=READ+WRITE)              (IDENTIFIER=[MIKE],ACCESS=NONE)    Total of 1 file.    $ SET FILE ZZZ.TXT /ACL=(IDENTIFIER=MIKE,ACCESS=NONE) /DELETE    $ DIRECTORY/ACL ZZZ.TXT    Directory DKA100:[LOGS]    ZZZ.TXT;1              (IDENTIFIER=[HERMAN],ACCESS=READ+WRITE)    Total of 1 file. 

Notice that ACEs are added at the top of the ACL by default. Use /AFTER=ace if you want to control the point at which it is inserted.

Note that SET FILE/ACL is technically obsolete in OpenVMS V7.3, but it still works. It is shown here because it works on older versions as well. On newer version of OpenVMS, use SET SECURITY object /ACL.

You may also choose to use the ACL editor to manage ACLs:

    $ EDIT /ACL ZZZ.TXT 

The OpenVMS ACL editor will start, allowing you to add, remove, or change ACEs using a full-screen editor. Use CRTL/Z to exit the ACL editor, and save the ACL. Press PF2 on the keypad for help ("/" on PC-style keyboards.)

Privileges That Override File Protections

Users holding certain privileges can bypass file protections as described below. The system manager grants these privileges to specific users and is responsible for granting them to users who have a legitimate need. Always remember that the judgment of the system manager in assigning UICs and privileges determines whether a given user can gain access to your files.

The relevant privileges are as follows:

SYSPRV—users who hold SYSPRV can access a file as if they were members of the SYSTEM category.

GRPPRV—if the holder of GRPPRV is in the same UIC group as the file owner, access is granted through the SYSTEM category.

BYPASS—a holder of BYPASS totally bypasses all file protections and is granted all types of access.

READALL—a holder of READALL is granted read access to the file, even if it is denied in ACL- and UIC-based protections.