Document revision date: 15 October 2001
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

Compaq PATHWORKS for OpenVMS (Advanced Server)
Server Administrator's Guide


Previous Contents Index


Chapter 4
Managing Directory and File Sharing

You use the ADMINISTER command-line interface to set up files and directories for sharing. To do this, you need to become familiar with the concepts and procedures described in this chapter:

4.1 Planning Directory and File Sharing

To serve your users most effectively, you should plan carefully for sharing files and directories. Some projects will require directory sharing, and some groups may need to share only certain files. Use the Shares Worksheet in the Compaq Advanced Server for OpenVMS Concepts and Planning Guide to help you set up your shares.

Sharing a directory makes the directory and the files located in it available to other network users. The Advanced Server integrates two levels of permissions for shared files and directories: share permissions, and file and directory access permissions.

Note

When you copy files or directories, security permissions set on them are discarded in addition to ownership and auditing information. The files inherit a new set of permissions from the directory into which they have been copied. If the new directory does not specify permissions for files, only the file's owner (the person who copied the file) will have permission to use the file.

In addition to the two levels of permissions supported by the Advanced Server, the OpenVMS file system imposes a set of protections, which are used if the Advanced Server and OpenVMS security model is enabled. These must be considered when managing shared directories. (For more information, see Section 4.1.2,Advanced Server Security Models.) Shared directories must have the appropriate OpenVMS system protections applied to them if interactive OpenVMS users and other OpenVMS processes need access to them.

4.1.1 Disk Resources

The Advanced Server supports the traditional OpenVMS file system, which includes RMS (Record Management Services) and is based on the Files-11, ODS-2 (On-Disk Structure) disk structure. ODS-5 disk volumes are treated as ODS-2 disk volumes. PATHWORKS for OpenVMS (Advanced Server) does not support the extended file system provided by OpenVMS Version 7.2 and higher for ODS-5 disk volumes. The extended file system, which provides Extended File Specifications and deep directories for greater compatibility with the file systems of Windows 95, Windows 98, Windows 2000, and Windows NT file systems, is supported by the Advanced Server for OpenVMS.

Disk resources include the disk devices on a server, the directories on those devices, and the files in the directories. With Advanced Server you can create a share for a directory, including the root directory for a disk, and specify access permissions for the share. Access permissions define the network users or groups permitted to access the share, and the kinds of operations that each may perform.

You cannot create a share for a file. Users access files through the directory share where the files reside. However, you can set access permissions on shares, directories, and files.

By configuring the server security model, you can enhance access permissions using OpenVMS file protection mechanisms.

4.1.2 Advanced Server Security Models

All Advanced Server users have either a network user account or access to the Guest account. The type of access allowed to each user account is determined by the access permissions set on the resource. Each network user account may be mapped to an OpenVMS user account. This mapping enables the Advanced Server to integrate network security with OpenVMS file access security.

You can define the level of integration by setting the server configuration parameter that specifies one of the following security models:

You can change the security model configuration parameter setting, using the Configuration Manager as described in Chapter 7, Managing Server Configuration Parameters. You can also enable the server to perform dynamic upgrading of network security on files it accesses. Files whose security is specified entirely according to PATHWORKS V5 for OpenVMS (LAN Manager) security are upgraded to PATHWORKS V6 for OpenVMS (Advanced Server) security. For more information, see Section 7.2.5.5, Enabling Dynamic Security Upgrade.

The following sections describe the security models in more detail. Each security model provides the security checks shown in Table 4-1, Security Checks.

Table 4-1 Security Checks
Security Model Checks Advanced Server Permissions? Checks OpenVMS Protections?
Advanced Server Only Yes No
Advanced Server and OpenVMS Yes Yes

4.1.2.1 Advanced Server Only Security Model

Whether the Advanced Server grants or denies a file access request depends on three factors:

To effectively implement the Advanced Server Only security model, keep the following in mind:

4.1.2.1.1 Windows NT Security Descriptors

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 about 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:

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

4.1.2.2.1 RMS Protections

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:

The default protections for directories and files are listed in Table 4-3.

Table 4-3 Default Values for RMS File and Directory Protections
Protections RMS Protection Codes
Directory S: RWED, O: RWED, G: RWED, W: RE
File S: RWD, O: RWD, G: RWD, W:R

For directories, this RMS protection allows read, write, execute, and delete access to the system, owner, and group; and read and execute access to the world. For files, the RMS protection allows read, write, and delete access to the system, owner, and group; and read access to world.

The administrator can change the RMS protection on a specific share by using the ADMINISTER MODIFY SHARE command with the /HOST_ATTRIBUTES qualifier to set the file and directory protections. For example,


$ ADMINISTER MODIFY SHARE share-name - 
_$ /HOST_ATTRIBUTES=(DIRECTORY_PROTECTION=(O:WRE,G:WR,W:R), - 
_$ FILE_PROTECTION=(O:WRED, G:WR, W: R)) 

Note

Because share data (such as host attributes) is cached when the first client accesses the share, the changes made to share protections are not reflected until either all users are disconnected from the share or the Advanced Server is restarted.
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 about 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 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 about 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:


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6556PRO_009.HTML