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, including:

• 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, Using ODS-5 Disk Volumes in the Advanced Server Environment, describes how to manage and use shares stored on ODS-5 disk volumes.

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 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, refer to Section 4.4, 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 on 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, systems that service interactive users as well as network users, where the more restrictive security checks are specifically desirable.

You can change the security model configuration parameter setting, using the Configuration Manager as described in Chapter 7, Managing Your Configuration.

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

For this security model:	The server checks Advanced Server permissions:	And 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:

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

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.

The OpenVMS operating system provides the following methods of assigning protection to files and directories:

• RMS protections
• 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 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.4 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, see the OpenVMS OpenVMS System Manager's Manual.

4.1.2.5 Windows NT ACL Information

The Advanced Server also stores Windows NT ACL information for shares and files on OpenVMS disk devices. The Windows NT ACL information includes the file ownership and permissions associated with the shared directories and files. This Windows NT ACL information is stored in extended ACLs, which are referenced by the OpenVMS ACLs. In this way, Advanced Server supports both OpenVMS and network security and ownership information.

To remove Windows NT ACEs (Access Control Entries) from any file on OpenVMS, use the SYS$SYSTEM:PWRK$DELETEACE.EXE utility provided with the Advanced Server software. Removing Windows NT ACEs from a file alters its attributes and security settings.

The PWRK$DELETEACE utility allows you to delete PATHWORKS V5 for OpenVMS (LAN Manager) security ACEs after upgrading to PATHWORKS V6 for OpenVMS (Advanced Server), saving disk resources. It is also useful for deleting PATHWORKS V6 for OpenVMS (Advanced Server) ACEs after the server has been rolled back to PATHWORKS V5 for OpenVMS (LAN Manager) and no longer has a use for the PATHWORKS V6 for OpenVMS (Advanced Server) ACEs.

The utility can remove other ACEs as well. It can remove PATHWORKS V4 ACEs after you upgrade. And it can be used to remove PATHWORKS for DOS ACEs, which are used by all types of PATHWORKS clients and should be removed only on files that are no longer accessed by the server. Finally, it can be used to delete Macintosh comment ACEs, used by the PATHWORKS for OpenVMS (Macintosh) server.

The following example shows how the PWRK$DELETEACE utility works.

$ MCR PWRK$DELETEACE Exit=x File Spec: DKA200:[LMSHARES.CSCSEC]*.* Cancel=x Delete V4 ACEs Y/N: Y Cancel=x Delete PW ACEs Y/N: Y Cancel=x Delete V5 security ACEs Y/N: Y Cancel=x Delete V6 security ACEs Y/N: Y Cancel=x Delete AFP Comment ACEs Y/N: Y DKA200:[LMSHARES.C CSCSEC]DEFAULT_SECURITY.EXAMPLE;1 ACEs removed DKA200:[LMSHARES.CSCSEC]NEW__20FOLDER.DIR;1 ACEs removed DKA200:[LMSHARES.CSCSEC]WYSIWYG.EXAMPLE;1 ACEs removed Exit=x FileSpec: x $

4.1.3 Controlling User Access to Disk Resources

To control user access, you assign permissions to shares. Share permissions determine which users can access the shared directory and the type of access those users are allowed. These permissions control network access to the directory.

4.1.3.1 Administrator Access

Server administrators can access all resources shared on a server, if they have the appropriate access permissions set for those resources. Access permissions apply to administrators as well as ordinary users. However, network administrators can always take ownership of a file or directory.

4.1.3.2 Group Access

If a user belongs to two groups, both of which are assigned access permissions for a resource, then that user has all access permissions assigned to both groups. For example, if the MUNCHKINS group has RW (Read and Write) access permission and the WINKIES group has E (Execute) access permission for the resource reports, then a user who is a member of both groups has RWE access permissions for that resource. A user account that is a member of a group that has been denied access gets no access. (See Section 3.2, Managing Advanced Server Groups, for more information about network groups).)

4.1.3.3 User Access

If you assign access permission explicitly to a specific user, that user has only that access permission, regardless of the permissions assigned to any groups that include that user. For example, a user who is a member of the groups MUNCHKINS and WINKIES, but who has been assigned only R (Read) access permission for the share GREATOZ has only read permission for GREATOZ. If the user is also in a group denied access, the user has no access.

4.1.3.4 Access Checks

In general, the ability to connect to a resource does not guarantee the ability to perform operations with that resource. If the user name and password match an account in the user accounts database, the user is granted access based on the permissions set on the resource. If the user name is invalid, the user may be able to access the resource as a Guest.

If the resource is a file or directory, the server performs the following checks:

1. For a file, the server checks access permission on the file and the share. Both the file and the share must grant the requested access. If access is permitted, the server continues to step 2. If the check fails at any level, the server denies access.
2. If the Advanced Server and OpenVMS security model is enabled, the server verifies OpenVMS access to the resource based on the host mapped OpenVMS user name.

The Advanced Server automatically creates special shares for administrative and system use. Only network administrators can change their properties. Table 4-3, Network Administrative Shares, lists some of the default shares created when the software is installed.

Table 4-3 Network Administrative Shares

Share Name	Type	Description
ADMIN$	Directory	The Admin share, a special administrative resource for remote administration.
C$	Directory	The root share, an administrative resource that provides a connection to the root of the file system. On an Advanced Server, C$ is equivalent to PWRK$LMROOT:[000000].
IPC$	IPC	The IPC share, an administrative resource that supports interprocess communication.

A server's administrative shares allow network administrators to perform certain tasks on the server, including examining the shares administering the server remotely, and running distributed applications.

Administrative shares include ADMIN$, IPC$, and disk administrative shares. They are hidden from most network users; only administrators can see information about them using the ADMINISTER command line interface. To display information about all shares, including administrative shares, include the /HIDDEN qualifier on the ADMINISTER command SHOW SHARES. For example:

LANDOFOZ\\TINMAN> SHOW SHARES/HIDDEN Shared resources on server "TINMAN": Name Type Description ------------ --------- ----------------------------------------- ADMIN$ Directory Admin Share ALP072$ Directory C$ Directory PATHWORKS share IPC$ IPC IPC Share NETLOGON Directory Logon Scripts Directory PAGE_TINMAN$ Directory PWLIC Directory PATHWORKS Client License Software PWLICENSE Directory PATHWORKS Client License Software PWODS5$ Directory PWROOT$ Directory PWTEST Directory PWUTIL Directory PATHWORKS Client-based Utilities USERS Directory Users Directory Total of 13 shares

The following sections explain the function of each administrative share and compare how these shares are shared.

4.2.1 The ADMIN$ Share

The ADMIN$ share controls access to server administration functions. A server's ADMIN$ share must be shared if that server is to be administered remotely. When a server starts, Advanced Server automatically shares ADMIN$. You cannot stop sharing the ADMIN$ share.

When you begin an administration session, Advanced Server makes a connection to the ADMIN$ share.

4.2.2 The IPC$ Share

The IPC$ share controls interprocess communication, such as communication between different components of a program, different computers running parts of a single program, or two programs working together. In the Advanced Server environment, interprocess communication occurs when a user or administrator:

• Views a list of a server's available resources.
• Administers the server remotely.
• Runs a distributed application.

Servers share the IPC$ share automatically. You cannot stop sharing the IPC$ share. When the IPC$ share is needed, Advanced Server makes a connection to it automatically.

4.2.3 Disk Administrative Shares

The Advanced Server automatically defines disk devices as shares by offering all mounted disk devices as autoshares (automatic shares) at server startup time. An autoshare points to the top-level (root) directory on the disk. For example, if you connect to the autoshare USER1_DISK$, a volume label, you access the directory USER1_DISK:[000000].

Only administrators can connect to disk administrative resources. This connection allows access to all directories and files on the disk. Administrators working at remote servers or clients cannot make connections if the ADMIN$ and IPC$ resource are not shared.

4.2.3.1 Autoshare Names

The Advanced Server creates an autoshare name using the OpenVMS volume label of the associated OpenVMS disk device. Autoshare names must conform to network resource naming restrictions (no more than 11 characters), with the last character a dollar sign ($), which identifies the share name as a hidden share.

You can use autoshare names when you create shares for directories by specifying either the physical device name or an OpenVMS logical name in the ADD SHARE command, as described in Section 4.3.2, Creating a Share.

4.2.3.2 Defining Autoshares

Sometimes the autoshare name created by the Advanced Server is not ideal for the situation. The Advanced Server lets you define your own autoshare names. This is useful when

• You have a disk device whose volume label exceeds the 11-character limit.
• You want to map a server device to a single letter to accommodate the DOS disk device-naming convention.
• You do not want to autoshare some devices.

The server cannot define devices with volume labels that exceed the 11-character limit as autoshares. When the server starts, disk devices with volume labels that exceed the limit are not shared, and an event is recorded in the Advanced Server log file, which is viewable with the ADMIN/ANALYZE command. (For information about using the ADMIN/ANALYZE command, refer to Section 6.1.4.2, Using the Event Logger to View Event Log Files.)

The Advanced Server lets you specify a logical name for the device in the share path. If you need to move the share later to another device, you simply assign the same logical name to the new device when you mount the device. Then users can continue to access the same share in the new location, as if nothing had changed.

For example, if DISK$USER2 is a logical name associated with disk device DKA200:, you can define an autoshare named DISK$USER2, enabling users to connect to the disk by mapping a network drive to \\server\DISK$USER2$, where server is the server name, and the final $ is required.

You use the Autoshare value in the OpenVMS Registry to define autoshare names for the server to create in addition to the autoshares that the server creates automatically. Use the NoAutoshare value to specify the names of devices that you do not want to autoshare.

The Autoshare and NoAutoshare parameters function as follows:

• If a volume label is specified with the NoAutoshare parameter, that device is not shared, but it is still available by its logical name.
• If a volume label is specified with the Autoshare parameter, that device is shared and mapped to the specified autoshare name.
• If a volume is not specified, Advanced Server creates an autoshare by default, so long as the volume label does not exceed the 11-character name limit. For a disk with a volume label longer than 11 characters, the Advanced Server does not automatically create a disk administrative share. In this case, you can define a logical name associated with the device, and then use the logical name in the list of devices associated with the Autoshare parameter.

If you are running Advanced Server in an OpenVMS cluster environment, see Section 4.2.3.5.1, Autosharing in an OpenVMS Cluster Environment, for information about defining autoshares and preventing autoshare creation on specific nodes in the cluster.