Document revision date: 30 March 2001

As enforced by the Advanced Server Only security model, network security uses Windows NT security descriptors for each shared directory and file.

A Windows NT security descriptor contains information such as the Windows NT owner of the file and a list of Windows NT users and groups with their respective access levels for that file.

These descriptors are stored in OpenVMS application access control entries (ACEs) that are included in the OpenVMS access control lists (ACLs) associated with the file.

4.1.2.2 Advanced Server and OpenVMS Security Model

In this security model, OpenVMS security is enforced in addition to the Advanced Server security model. The OpenVMS security is based on the OpenVMS user account to which the network user is mapped.

An OpenVMS account identifies a user to the OpenVMS operating system. The account includes the user's name, a password, privileges, and access to directories and files associated with the account. Network user accounts are associated with OpenVMS user accounts by means of host mapping. For more information on host mapping, see Section 3.1.16, User Account Host Mapping.

OpenVMS stores a security profile for each directory or file. The security profile contains the following types of information:

• User identification code (UIC) of the owner of the object (file, directory, or device). The system uses this element to help interpret the RMS protection code.
• Protection code defining access to objects (files, directories, or devices) based on categories of system, owner, group, and world. This protection code controls broad categories of users.
• The access control list (ACL) identifying the users and groups allowed or denied access to the file or directory. The ACL contains an entry for each user and group. These entries are called access control entries (ACEs).

In short, the OpenVMS operating system provides two methods of assigning protection to files and directories:

• RMS protections (see Section 4.1.2.2.1, RMS Protections)
• Access control lists (ACLs) (see Section 4.1.2.2.2, Access Control Lists (ACLs))

RMS sets protection on files and directories based on user identification codes (UICs). A UIC consists of a group code and a user code assigned to every OpenVMS user by the system administrator. The user's UIC determines which categories a user belongs to. Table 4-2, OpenVMS Group Codes, lists and describes the group codes.

Table 4-2 OpenVMS Group Codes

UIC Category	Includes
System (S)	Users with SYSTEM privileges (the OpenVMS privilege SYSPRV) or users with low group numbers in their UICs, as determined by the system administrator.
Owner (O)	The user who is the owner of a file or directory. The user code of the UIC associated with the file or directory matches the user code of the UIC of a user.
Group (G)	All users who have the same group code in their UICs.
World (W)	All users regardless of UIC.

RMS assigns file protections for each of these categories according to the following format:

• R for read-only access
• W for write access
• E for execute access
• D for delete access

The default protections are: System: RWED, Owner: RWED, Group: no access, World: no access. This RMS protection allows read, write, execute, and delete access to the system and to the owner of the file, but users in the same group and other users have no access to the file.

4.1.2.2.2 Access Control Lists (ACLs)

An access control entry (ACE) is an entry in an access control list (ACL) that controls access to files and directories by resource identifiers. ACLs give you more control than RMS protections. For example, with RMS, the only way to grant READ access to users in different UIC groups is to grant World Read (W:R) access. In contrast, with ACLs, you can provide users from several UIC groups with access to a file or directory without granting World access, and you can deny specific users access to specific files.

If you use both RMS protections and ACLs, OpenVMS checks ACEs in the ACLs before it checks the RMS protections. For more information on RMS protections and ACLs, refer to the OpenVMS System Manager's Manual.

4.1.3 The Advanced Server and Windows NT Security Information

The Advanced Server supports both OpenVMS and network security, and ownership information. It achieves this by storing Windows NT security descriptors for directories and files on OpenVMS disk devices. (For more information on Windows NT security descriptors, see Section 4.1.2.1.1, Windows NT Security Descriptors.

The following sections explain how the Advanced Server handles file security information and describes utilities you can use to manipulate this information.

4.1.3.1 Inheritance of Directory Permissions

Each Windows NT directory has two sets of permissions: (A) directory-specific security permissions that provide access control to the directory itself and (B) inheritable permissions that will be inherited automatically by any file created in that directory, becoming the default access permissions for that new file.

The Advanced Server is designed to conform with Windows NT security behavior. When you create a file in a shared directory, the parent directory's inheritable permissions (B) are propagated to that file to become the file's access permissions. When you create a subdirectory, both the parent directory's access control permissions (A) and inheritable permissions (B) propagate to the subdirectory becoming the subdirectory's access control (A) and inheritable permissions (B), respectively.

4.1.3.2 Inheritance of Ownership

In conformance with Windows NT security behavior, Advanced Server security is designed to assign ownership of a file or directory to the user who creates the file or directory. The owner can always control access to the file or directory by changing the permissions set on it.

4.1.3.3 ACEs and OpenVMS Volume Index Files

Every OpenVMS file has a file header block stored in the volume index file, INDEXF.SYS. Each file header is limited to 512 bytes. The ACL for a file is stored in the file's header. When a file contains several ACEs, it may exceed the 512-byte limit, and a secondary file header (known as an extension file header) is allocated.

When a file has a large number of "PATHWORKS" ACEs (displayed as PATHWORKS ACES, these are ACEs created by Advanced Server or PATHWORKS servers; see Section 4.1.3.8, Displaying Advanced Server for OpenVMS and PATHWORKS ACEs), the secondary headers required to store the ACEs will consume additional space in the index file. As the index file extends to provide more headers, the space available for other files is reduced, and the index file itself becomes fragmented. In addition, there is a limit to the number of times the index file can be extended. Its header can become full from mapping its own multiple extensions.

You can reduce the number of ACEs by using local groups in permissions lists for files and directories, rather than by adding individual users or global groups. Ideally, each file and directory permissions list should reflect only local groups, and no two entries in a permissions list should duplicate the same permissions. The Advanced Server for OpenVMS can help reduce the number and size of the ACEs created, and thereby reduce the consumption of index header blocks used for secondary headers.

For example, the file server parameter Store_Security_Aces allows you to control the amount of Windows NT security information stored with the file at file creation. By default (parameter value equals YES), the file server writes a complete set of Windows NT security information to a new file. By changing the value of the Store_Security_Aces parameter to NO, only the ownership information is represented in the file's ACL, excluding all the file access permission ACEs. For more information on this parameter, see Section 4.1.3.6, Streamlining Security Information Storage and Lookups. This can make more efficient use of disk space.

Note that there are tradeoffs for using the Store_Security_Aces=NO setting. For example, while conserving disk space, additional run-time is required to determine access permissions for files that do not have explicit access permissions associated with them. Section 4.1.3.6, Streamlining Security Information Storage and Lookups, discusses the tradeoffs in more detail, and explains how to recover from over consumption of disk space caused by oversized file security descriptors (excessive ACEs on a file) or inappropriate propagation of ACEs to files.

4.1.3.4 How the File Server Reads Windows NT Security Information on Files

When a client accesses a shared file whose ACL contains the complete Windows NT security descriptor information (that is, owner, group, discretionary access control lists (DACLs) and system access control lists (SACLs)), then the Advanced Server uses that information to determine the access rights to the file.

If the file lacks any or all of the required Windows NT security descriptor information, the file server builds a complete security descriptor for the file, getting the required security descriptor information from the directory hierarchy above the file. (A file lacks all Windows NT security information if it was not created by an Advanced Server for OpenVMS or by a PATHWORKS Advanced Server; an example is a file that was created on an OpenVMS system before the directory became shared.)

If, for example, a file has owner information but no group, DACL, and SACL information, the server looks up the directory structure, level by level, as far as the device root, but a maximum of up to 15 levels, until it finds enough information to build a complete Windows NT security descriptor for that file. If nothing is found in the search all the way to the root, the server creates a default descriptor for the file in which Everyone has full access control.

The file server might not find all the required file security information at the same directory level. In some cases, it might extract the information from several different directory levels.

For example, given a file with no security information available, the server might find the owner information in the file's parent directory, but then have to search up one or more additional directory levels to find the other information. When the file server finds a directory that has the Windows NT security descriptor information it is seeking, it inserts the needed information in the file's security descriptor. The owner of the file was already determined from the file's parent directory: the file server does not use the higher directory's ownership for the file's security descriptor.

In summary, the file server must determine the access rights for a file in these circumstances:

• If the complete Windows NT security descriptor is explicitly stored in a file's ACL, the file server uses this information to determine a user's access rights (without needing to look up the directory structure to determine additional Information).
• If the file has no security information, the file server looks up the directory structure for the information required to build the file's Windows NT security descriptor. If no security information is found in the directory hierarchy (from that file's parent directory up to the device root), the server creates a default security descriptor for the file, giving Everyone access to the file.
• If the file has some but not all of the security information in its security descriptor, the file server looks up the directory structure for the missing information.
• When searching up the directory structure for the needed information, the file server might either:
  • Find all the information at the parent directory level, or if none is available there, all at a higher directory level
  • Find part of the information at one level, and pull the rest of the missing information from one or more levels above that level
  • Not find the information at all (searching in vain up to the device root level)

One subtle difference exists in how and when the Advanced Server and Windows NT build security information for a file. By default, both the Advanced Server and Windows NT are designed to write complete security information for a file when the file is created, propagating it from the parent directory as necessary. However, the Advanced Server file server allows you to change this default behavior to make more efficient use of security information and disk space. For more information, see the discussion of the Store_Security_Aces parameter in Section 4.1.3.6, Streamlining Security Information Storage and Lookups.

As a result of making this change, when a file is created in a shared directory, only the owner information is stored with the new file. When a user attempts to access the file, the server uses security information from the parent directory structure to dynamically build a Windows NT security descriptor for the file. The file server does not modify the file or the security information stored with the file in any way.

After the file server has used the dynamically built Windows NT security descriptor to determine whether the user has permission to access the file, the dynamically built Windows NT security descriptor is discarded. The next time a client attempts to access the file, the file server again dynamically builds a Windows NT security descriptor to determine the access permission for the file.

A significant consequence of this behavior, which is unique to the Advanced Server file server, is that the file security information for a file (whose security descriptor is built dynamically) can change when the security information in the directory structure above it changes. For example, assume a directory named ACCOUNT is owned by user JOHNSON and has full access for Everyone. User CARTER creates file CABINET in that directory. On a Windows NT system, the new file's security descriptor will include:

• CARTER as owner (creator gets ownership)
• Full access for Everyone (permissions inherited from the parent directory, ACCOUNT)

By default, the same would be true on an Advanced Server share. But, if the Store_Security_Aces parameter is changed from the default YES to NO, the security descriptor for file CABINET sets CARTER as the owner but does not store any access rights information. Nevertheless, when a client attempts to access the file CABINET, the file server dynamically determines that access to file CABINET is full access for Everyone (determining the access permissions from the parent directory, ACCOUNT).

If the access permissions for the ACCOUNT directory are changed to read access for Everyone, then on a Windows NT system, and by default, on an Advanced Server share, the access for file CABINET remains full access for Everyone (as originally inherited from the parent directory when CABINET was created). But, if the value of the Advanced Server Store_Security_Aces parameter is NO, the access for the shared file CABINET would be READ access for Everyone: the access permissions were not stored with CABINET at file creation, so the server builds the file's security descriptor dynamically, determining the file's access permissions from the parent directory, ACCOUNT.

4.1.3.6 Streamlining Security Information Storage and Lookups

As noted previously, the default propagation of security information to new files in shared directories can require that secondary headers be allocated for these files to store the security ACEs. Over time, this excessive consumption of file headers can cause excessive growth of the volume's index file, reducing the disk space available for creating new files. Techniques for minimizing file header usage are described later on in this section.

If disk space is not a problem, multiple extensions of the index file can still fragment the file across the volume, making access to the file headers less efficient, and eventually making further extension of the index file impossible. The solution is to make the index file contiguous, and make it large enough to help eliminate the need for further extensions in the future. However, be sure not to make the index file too large, or else space will be wasted.

You can make the volume and all of its files (including the index file) contiguous by performing a simple backup and restore of the volume. In addition, before doing the restore, you can initialize the volume with a larger index file, if appropriate. However, there is currently no easy way to determine how much the index file has grown, how many times it has grown (how fragmented it has become), or how many free headers it currently contains. For details on making the index file contiguous and estimating an appropriate size for the index file, see Section 4.1.3.6.1, Managing the Index File on a Volume with Shared Files.

If consumption of disk space is a problem, you can change the Store_Security_Aces OpenVMS Registry parameter to NO. The default value (YES) causes the file server to write a complete set of Windows NT security information to a new file's ACL. By changing the parameter value to NO, you limit the amount of security information stored with the new file: only the ownership information is represented in the file's ACL, and all the file access permission ACEs are excluded. Use PWRK$REGUTL to modify the value of the Advanced Server OpenVMS registry server parameter. This parameter is stored in the registry key:

SYSTEM\CurrentControlSet\Services\AdvancedServer\FileServiceParameters

Note the tradeoffs between using the default (YES) or changing the parameter to NO, described in Table 4-3. In short, setting the parameter to NO saves file header usage but might result in increased file access times. Because the security information is not propagated to the files in a directory, the file server must look up the directory tree to determine missing information.

Table 4-3 Tradeoffs Regarding the STORE_SECURITY_ACES Parameter Settings

	If using the default (store all security information)	If setting to NO (store owner information only)
Server Behaves as Windows NT does?	Yes	No
Performance	Faster	Slower
File Header Usage	Higher	Lower
How Security Settings Are Determined	Direct from files	Dynamically, using the file's directory tree

If security problems arise because of inappropriate ACEs on files, or if you want to minimize consumption of disk space by index blocks required for storage of ACEs, use the Advanced Server utility SYS$SYSTEM:PWRK$FIXACE.EXE. This utility optimizes disk storage by compressing ACEs, removing unnecessary ACEs, and preventing ACEs from being propagated to files created in shares.

Invoke this utility as follows:

$ MCR PWRK$FIXACE

In addition, you can clean up unwanted ACEs by using the PWRK$DELETEACE utility, as documented in Section 4.1.3.7, Removing PATHWORKS ACEs. This utility will help you reclaim disk space.

4.1.3.6.1 Managing the Index File on a Volume with Shared Files

This section provides examples of the image backup and restore operations that make the index file (and all other files) on a volume contiguous.

To make the index file on a volume contiguous, follow these steps. For details, refer to the OpenVMS System Manager's Manual.

1. Perform an image backup of the volume, using the OpenVMS DCL BACKUP/IMAGE command.
2. If a larger index file is indicated, manually reinitialize the volume, using the /HEADERS qualifier to specify an appropriate value for the number of headers to allocate. For more information on how to determine the appropriate value, see Section 4.1.3.6.2, Determining the Number of Index File Headers to Allocate.

   $ INITIALIZE/HEADERS=n disk_volume:

3. Restore the backup using the OpenVMS DCL BACKUP/IMAGE command. If the disk was manually initialized in step 2, then the /NOINITIALIZE qualifier is also necessary to preserve the new index file size.

This section explains how to determine whether a larger index file is indicated, and if so, how many file headers to specify with the INITIALIZE/HEADERS command. As stated previously, there is no easy way to determine how much the index file has grown, how fragmented it has become, or how many free headers it currently contains.

You can estimate whether the index file should be made larger by monitoring the size of the index file and the total count of all shared files on the volume. Suppose you observe that an index file is growing rapidly, most likely because of an increase in the number of shared files on the volume. If you can estimate how much the number of shared files might grow in the future, you can calculate how much larger the index file might become as well. From this value, you can approximate the total number of headers to specify.

If you suspect that the index file is fragmented, but have no data to support any estimates, you may still perform the image backup and restore without changing the index file size, and then start monitoring the volume as described above.

For example, assume earlier monitoring revealed these results:

$ DIRECTORY/SIZE DKB0:[000000]INDEXF.SYS Directory DKB0:[000000] INDEXF.SYS;1 24426 Total of 1 file, 24426 blocks. $ DIRECTORY/GRAND_TOTAL DKB0:[SHARE_DIRECTORIES...] Grand total of 56 directories, 13512 files.

Assume current monitoring reveals the following results:

$ DIRECTORY/SIZE DKB0:[000000]INDEXF.SYS Directory DKB0:[000000] INDEXF.SYS;1 90704 Total of 1 file, 90704 blocks. $ DIRECTORY/GRAND_TOTAL DKB0:[SHARE_DIRECTORIES...] Grand total of 73 directories, 37182 files.

Then you can calculate the increase in file count and the associated increase in the size of the index file. In this example, these calculations are as follows:

Shared file count increase = 37,182 - 13,512 = 23,670 files Index file size increase = 90,704 - 24,426 = 66,278 blocks.

If you estimate that the number of shared files will grow to 120,000 in the lifetime of the current configuration, then the number of files will have increased by 82,818 files (subtract 37,182 from 120,000).

From that calculation, you can estimate the index file growth by use of simple proportions, where the ratio of the projected file count increase to the projected index file header increase (n) is equal to the ratio of the observed file count increase (23,670 files) to the observed index file header increase (66,278 blocks):

82,818 23,670 ------ = ------ n 66,278

Thus, the projected index file header increase (n) is calculated as follows:

82,818 * 66,278 n = --------------- = 231,897 blocks 23,670

The total size of the future index file will then be its current size plus the projected increase, or:
24,426 + 231,897 = 256,323 blocks

Given that each file header occupies one disk block, and assuming for simplicity that the entire index file consists of file headers (this is an overestimation), the total number of headers needed in the future is 256,323. Thus, to initialize the volume, you would specify this value for the /HEADERS qualifier in the INITIALIZE command mentioned in step 2 in the preceding section.

You can also apply this same reasoning independently to any other product that maintains a large number of files on the volume, such as MAIL or ALL-IN-1, or products such as POLYCENTER HSM (Hierarchical Storage Management) for OpenVMS that maintain file headers in INDEXF.SYS when shelving specified files.

	privacy and legal statement
6543PRO_009.HTML