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

• 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.
• PATHWORKS Administrative Resources--- describes the disk administrative resources.
• 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.

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 PATHWORKS 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 PATHWORKS Advanced Server 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 directory access permissions with the SET FILE/PERMISSIONS command. (See Section 4.4.5, Specifying File and Directory Access Permissions.)

In addition to the two levels of permissions supported by the PATHWORKS 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.2.2, Network 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.2.1 Disk Resources

PATHWORKS for OpenVMS supports the OpenVMS file system, which includes RMS (Record Management Services) running on ODS2 (On-Disk Structure --- Files-11).

Disk resources include the disk devices on a server, the directories on those devices, and the files in the directories. With PATHWORKS Advanced Server, you can create a share for a directory including the root directory for a disk and then specify access permissions for the share to specify the users or groups permitted to access the share. You cannot create a share for a file. Users access files through the directory share where the files reside. You protect files by setting access permissions on the shares, directories, or files; you can enhance access permissions using OpenVMS file protection mechanisms.

4.2.2 Network Security Models

All PATHWORKS Advanced Server users have either a PATHWORKS Advanced Server user account or access to the Guest account; file and directory access by each user account is determined by the PATHWORKS Advanced Server access permissions set on the resource. Furthermore, each PATHWORKS Advanced Server user account may be mapped to an OpenVMS user account. This mapping enables PATHWORKS Advanced Server to integrate PATHWORKS Advanced Server security with OpenVMS file access security.

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

• PATHWORKS Advanced Server Only (default)
  Only PATHWORKS Advanced Server security is enforced; OpenVMS access checks are bypassed. PATHWORKS 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, PATHWORKS Advanced Server Only security is established on your server. PATHWORKS Advanced Server Only security is sufficient for most network environments.
• PATHWORKS Advanced Server and OpenVMS
  Both PATHWORKS Advanced Server security and OpenVMS security are enforced. If the user's access request passes the PATHWORKS Advanced Server security check, PATHWORKS Advanced Server checks the OpenVMS security set on the requested resource, determined by the OpenVMS user account to which the PATHWORKS Advanced Server user account maps. Access is granted when the user passes both security checks. For information on how PATHWORKS Advanced Server accounts map to OpenVMS accounts, see Section 3.3.12, User Account Host Mapping.
  The PATHWORKS 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. (See Chapter 7, Managing Your Configuration.)

The following sections describe the PATHWORKS Advanced Server security models. Each security model provides the security checks shown in the following table.

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

Advanced Server Only Security Model

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

• The PATHWORKS security model in effect on the server
• Permissions established for a group
• Permissions established for a user

To effectively work with the PATHWORKS Advanced Server security model, keep the following in mind:

• Users cannot use a directory or file unless they have been granted permission to do so or belong to a PATHWORKS Advanced Server user group that has permission to do so.
• Share permissions are cumulative except that the No Access permission overrides all other permissions. For example, if the MUNCHKINS group has Write permission for a file while the WINKIES group has only Read permission and SCARECROW is a member of both groups, SCARECROW is granted Read and Write permission. However, 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 a PATHWORKS Advanced Server group that 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. Users who are members of the Administrators group 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.

Advanced Server and OpenVMS Security Model

An OpenVMS account identifies a user to the OpenVMS operating system. An account includes the user's name, a password, privileges, and access to directories and files associated with the account. You associate PATHWORKS Advanced Server and OpenVMS user accounts with host mapping.

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

• RMS protections
• Access control lists (ACLs)

RMS Protections

The Record Management Service (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. The following table 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.

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 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 System Manager's Manual.

User host mapping associates the PATHWORKS Advanced Server user accounts to OpenVMS user accounts. User host mapping is described in Section 3.3.12, User Account Host Mapping.

4.2.3 Controlling User Access

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.2.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, Administrators can always take ownership of a file or directory.

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

4.2.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.2.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 can access the resource as a Guest.

If the resource is a file or directory, the server performs the following additional 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 PATHWORKS Advanced Server automatically creates special shares for administrative and system use. Only Administrators can change their properties. The following table lists some of the default PATHWORKS Advanced Server shares created when the software is installed.

Table 4-3 PATHWORKS Advanced Server Administrative Shares

Share Name	Type	Description
ADMIN$	Directory	The Admin share, a special administrative resource for remote administration.
C$	Directory	The PATHWORKS share, an administrative resource that provides a connection to the root of the file system. On a PATHWORKS 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 resources let network administrators perform certain tasks on the server, including examining the resources, administering the server remotely, and running distributed applications.

Administrative resources include ADMIN$, IPC$, and disk resources. They are hidden from most network users; only administrators can see information about them using the ADMINISTER command line interface. The following sections explain the function of each administrative resource and compares how these resources are shared in PATHWORKS Advanced Server security and OpenVMS security environments.

4.3.1 The ADMIN$ Resource

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

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

4.3.2 The IPC$ Resource

The IPC$ resource 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 PATHWORKS 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$ resource automatically. You cannot stop sharing the IPC$ resource. When the IPC$ resource is needed, PATHWORKS Advanced Server makes a connection to it automatically.

4.3.3 Disk Administrative Resources

Disk administrative resources represent the server's disk drives. They are automatically shared as autoshares whenever you start a server. 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].

By default, the autoshare name C$ always points to the device containing the LANMAN root directory.

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

4.3.4 Autoshares: Shared Disk Devices

The PATHWORKS Advanced Server automatically defines disk devices as shares by offering all mounted disk devices as autoshares (automatic shares) at server startup time. By default, autoshares are hidden. A hidden share is visible only to members of the Administrators group, and only members of this group can connect to autoshares. When you connect to an autoshare, you are at the top-level (root) directory of the device and have access to any subdirectory or file in the directory tree.

The PATHWORKS 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. (See Section A.4, Defining Autoshares.)

You can map any OpenVMS system logical device as if it were an autoshare. For example, if DISK$USER2 is a system logical pointing to DKA200:, an Administrator can connect to it by mapping a network drive to \\server\DISK$USER2$. (The final $ is required.)

4.3.4.1 Autoshare Names

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

The following table shows examples of device names and associated autoshare Names.

Table 4-4 Sample Autoshare Names

Device	Volume Label	Autoshare Name
DOT$DUA0:	AXPVMS071	AXPVMS071$
DOT$DUA1:	USERS_1	USERS_1$
DOT$DUA2:	USERS_2	USERS_2$
DOT$DUA3:	WORK_DISK055	None: the volume label exceeds the 11-character limit.

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 PATHWORKS log (viewable with the ADMIN/ANALYZE command). These devices can be used in adding shares for directories by specifying either the physical device name or an OpenVMS logical name in the ADD SHARE command. (See Section 4.4.1, Creating a Share on PATHWORKS Advanced Server.)

4.3.4.2 Synchronizing Autoshares with a Disk Device

If you mount a disk device after the server has started, PATHWORKS Advanced Server does not automatically list the device in a display of available devices. You can synchronize the available devices in your list with the SET COMPUTER command.

To synchronize autoshares:

Use the SET COMPUTER /AUTOSHARE_SYNCHRONIZE command. This resynchronizes the computer's table of autoshares. For example:

LANDOFOZ\\TINMAN> SET COMPUTER TINMAN/AUTOSHARE_SYNCHRONIZE %PWRK-S-AUTOSHRSYNCHED, autoshare synchronization was successful LANDOFOZ\\TINMAN>

4.4 Managing Shared Directories and Files

PATHWORKS Advanced Server allows you to create shared and personal shared directories. Some shares are provided by default.

When you install PATHWORKS Advanced Server software, it creates the default shares shown in the following table.

Table 4-5 PATHWORKS Advanced Server Default Shares

Share Name	Description
USERS	Contains user home directories. This shared directory is created only when logon validation is enabled.
NETLOGON	Default location for logon scripts. This directory is shared if the Netlogon service is running.
PWLIC	PATHWORKS Client Licensing Software
PWLICENSE	PATHWORKS Client Licensing Software
PWUTIL	Default location for PATHWORKS Advanced Server utilities.