HP OpenVMS Systems

HP Advanced Server for OpenVMS
Server Administrator's Guide

To simplify creating a new group, you can use the COPY GROUP command to copy an existing group to the new group, with a new name, keeping the members and description from the previous group. For example, to form a new group called QUADLINGS from an existing group called MUNCHKINS, use the following command:

LANDOFOZ\\TINMAN> COPY GROUP MUNCHKINS QUADLINGS
%PWRK-S-GROUPCOPY, group "MUNCHKINS" copied to "QUADLINGS" in domain "LANDOFOZ"

LANDOFOZ\\TINMAN>

This command copies the description and group members from MUNCHKINS to the new group named QUADLINGS. You can display information about the new group using the SHOW GROUPS/FULL command. For example, the following command displays the type, description, and members of the QUADLINGS group:

LANDOFOZ\\TINMAN> SHOW GROUPS QUADLINGS/FULL

Groups in domain "LANDOFOZ":

Group Name      Type             Description
----------      ------           -----------------------------
QUADLINGS        Local            Oz local group
    Members: [US]LION,[US]SCARECROW

  Total of 1 group

LANDOFOZ\\TINMAN>

3.2.5 Modifying a Group

To add a member to an existing group, use the MODIFY GROUP command with the /ADD_MEMBERS qualifier. For example, to add the user LION to the group MONKEYS, enter the following command:

LANDOFOZ\\TINMAN> MODIFY GROUP MONKEYS/ADD_MEMBERS=LION
%PWRK-S-GROUPMOD, group "MONKEYS" modified on domain "LANDOFOZ"

LANDOFOZ\\TINMAN> SHOW GROUP MONKEYS

Groups in domain "LANDOFOZ":

Group Name      Full Name       Type     Description
----------      ---------       ------- ------------------------
MONKEYS                         Global   Winged monkeys
    Members: [US]LION

 Total of 1 group)

LANDOFOZ\\TINMAN>

To remove a member from a group, use the MODIFY GROUP command with the /REMOVE_MEMBERS qualifier. For example, to remove SCARECROW from the group MUNCHKINS, enter the following command:

LANDOFOZ\\TINMAN> MODIFY GROUP MUNCHKINS/REMOVE_MEMBERS=SCARECROW
%PWRK-S-GROUPMOD, group "MUNCHKINS" modified on domain "LANDOFOZ"

LANDOFOZ\\TINMAN>

To change the group description, use the MODIFY GROUP/DESCRIPTION command, as in the following example:

LANDOFOZ\\TINMAN> MODIFY GROUP MUNCHKINS/DESCRIPTION="First Floor"
%PWRK-S-GROUPMOD, group "MUNCHKINS" modified on domain "LANDOFOZ"

Deleting a group removes only that group; it does not delete user accounts or global groups that are members of the deleted group. You cannot recover a deleted group.

Internally, the Advanced Server recognizes every group by its security identifier (SID), which is used when assigning permissions to a resource. If you delete a group and then create another group with the same group name, the new group does not inherit access to any resources available to the old group because the groups have different SIDs. To delete a group, use the REMOVE GROUP command, as in the following example:

LANDOFOZ\\TINMAN> REMOVE GROUP QUADLINGS

Each group is represented by a unique identifier which is independent
of the group name.  Once this group is deleted, even creating an
identically named group in the future will not restore access to
resources which currently name this group in the access control list.
Remove "QUADLINGS" [YES or NO] (YES) : YES
%PWRK-S-GROUPREM, group "QUADLINGS" removed from domain "LANDOFOZ"

LANDOFOZ\\TINMAN>

The command deletes the group QUADLINGS from the LANDOFOZ domain.

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:

• Section 4.1, Planning Directory and File Sharing, describes how to plan the sharing of directories and files for your users and the access permissions you can set.
• Section 4.2, Administrative Shares, describes the disk administrative resources.
• Section 4.3, Managing Shared Directories and Files, describes how to secure directories and files, share a directory on the OpenVMS system, audit directory and file access, and take ownership of directories and files. It also describes how to manage Advanced Server shares from Windows NT Server computers.
• Section 4.4, Unicode and Extended Character Sets, describes how the Advanced Server can support extended character sets (including certain Unicode characters). The supported extended characters can be used in file and share names, and other objects manageable by the Advanced Server.
• Section 4.5, Using ODS-5 Disk Volumes in the Advanced Server Environment, describes how to manage and use shares stored on ODS-5 disk volumes.
• Section 4.6, File Names for Files Stored on the Advanced Server, describes the conventions for Advanced Server file names and how they are stored on the server.

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 HP 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.

• Share permissions specify the maximum access possible for a user or group on all files and directories residing on that share. For example, setting share permissions to Read for the group Everyone would allow all users to read a file, and prevent any user from altering the contents of the file. You set share permissions using the ADD SHARE and MODIFY SHARE commands. If you do not specify share permissions when you add the share, the default is to allow all users to access the share.
• File and directory access permissions specify the access that a group or user is granted to a particular directory or file in a shared directory. You set file and directory access permissions with the SET FILE/PERMISSIONS command, as described in Section 4.3.6, Specifying File and Directory Access Permissions.

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

Advanced Server for OpenVMS supports the following OpenVMS file systems:

• ODS-2, the traditional OpenVMS file system, which is based on the Files-11 disk structure
• ODS-5, the optional extended file system provided by OpenVMS Version 7.2 and higher, which provides Extended File Specifications and deep directories

For more information about Extended File Specifications, refer to the OpenVMS Guide to Extended File Specifications. For details about managing disk resources on ODS-5 disk volumes, see Section 4.5, Using ODS-5 Disk Volumes in the Advanced Server Environment.

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:

• Advanced Server Only (default)
  Only network security is enforced; OpenVMS access checks are bypassed. Advanced Server Only is the default security model when you install the server software. Unless you change the default parameter setting for the security model, Advanced Server Only security is established on your server. Advanced Server Only security is sufficient for most network environments.
• Advanced Server and OpenVMS
  Both network security and OpenVMS security are enforced. If the user's access request passes the Advanced Server security check, Advanced Server checks the OpenVMS security set on the requested resource, determined by the OpenVMS user account to which the network user account is mapped. Access is granted when the user passes both security checks. For information about how network user accounts are mapped to OpenVMS user accounts, see Section 3.1.16.2, Establishing User Account Host Mapping.
  The Advanced Server and OpenVMS security model is best suited for environments that require the additional control provided by the OpenVMS operating system. For example, this model would benefit systems with legacy OpenVMS data already protected by the elaborate OpenVMS security settings. Rather than having to establish the same security settings at the server level, you could simply give Everyone full control and let OpenVMS security settings determine access. Note that use of the Advanced Server and OpenVMS security model results in the extra overhead of validating both the Advanced Server and OpenVMS settings.

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.

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

• The security model in effect on the server
• Permissions established for the group of which the user is a member
• Permissions established for the user

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

• Network users cannot use a directory or file unless they have been granted permission to do so or belong to a group that has permission to do so.
• Share permissions are cumulative, except that the No Access permission overrides all other permissions. For example, the MUNCHKINS group has Write permission for a file and the WINKIES group has only Read permission. User SCARECROW is a member of both groups; therefore, SCARECROW is granted Read and Write permission.
  If you change the WINKIES group's permission for the file to No Access, SCARECROW cannot use the file even though he is a member of the MUNCHKINS group, which still has access to it.
• The user who creates a file or directory is the owner of that file or directory. The owner can always control access to the file or directory by changing the permissions set on it. Network administrators can always take ownership of a file or directory.
  For files and directories that existed on an OpenVMS device before the share was created, the owner of the file or directory is set to be the user who created the share.
• The easiest way to administer security is by setting permissions for groups, not individual users. Typically, a user needs access to many files. If the user is a member of a group that has access to the files, you can end the user's access by removing the user from the group rather than changing the permissions on each of the files.

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:

• 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.

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 about RMS protections and ACLs, refer to the HP 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 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.