Document revision date: 30 March 2001

To remove some or all ACEs associated with Advanced Server for OpenVMS and PATHWORKS products, use the SYS$SYSTEM:PWRK$DELETEACE.EXE utility provided with the Advanced Server software.

The PWRK$DELETEACE utility allows you to selectively remove:

• PATHWORKS and Advanced Server for OpenVMS file attribute ACEs (the utility refers to these ACEs as "PW ACEs"). When you display file ACEs (see Section 4.1.3.8, Displaying Advanced Server for OpenVMS and PATHWORKS ACEs), these begin with "UNKNOWN=%X80" and are used by Advanced Server for OpenVMS, PATHWORKS V6 for OpenVMS (Advanced Server), and PATHWORKS V5 for OpenVMS (LAN Manager) to store file attributes and dates. These ACEs should be removed only on files that are no longer accessed by the server.
• Advanced Server for OpenVMS and PATHWORKS V6 for OpenVMS (Advanced Server) security ACEs. These ACEs begin with "UNKNOWN=%X86" and are used to store Windows NT-style security information, such as owner, DACL, and SACL.
• PATHWORKS V5 for OpenVMS (LAN Manager) security ACEs. These begin with "UNKNOWN=%X82".
• PATHWORKS V4 ACEs. V4 ACEs begin with "IDENTIFIER =PCFS$READ", "IDENTIFIER=PCFS$UPDATE", or "APPLICATION".
• PATHWORKS for OpenVMS (Macintosh) comment ACEs (the utility refers to these as "AFP Comment ACEs").

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.8 Displaying Advanced Server for OpenVMS and PATHWORKS ACEs

If you execute the DCL command SHOW SECURITY, DIRECTORY/SECURITY, or DIRECTORY/FULL for files that contain Advanced Server for OpenVMS and PATHWORKS ACEs, the hexadecimal representation for each ACE is no longer displayed. Instead, the commands summarize the total number of ACEs encountered for each file in this message:

"Suppressed n PATHWORKS ACES."

To display the suppressed ACEs, use the DCL DIRECTORY command with the /NOSUPPRESS qualifier along with either the /FULL, /SECURITY, or /ACL qualifier.

4.1.4 Controlling User Access to Disk Resources

To control user access, you can assign permissions to shares. By default, when a directory is shared, all users have full access to the share. You can set or modify the permissions at the share level (using the ADD SHARE/PERMISSIONS= or MODIFY SHARE/PERMISSIONS= command). You can also assign permissions to specific files or directories within a shared directory (using the SET FILE/PERMISSIONS= command).

Share permissions determine which users can access the shared directory or file, and the type of access those users are allowed. These permissions control network access to the directory or file.

In general, the simplest method to control access to disk resources is to assign FULL access for Everyone to the share (the default), and then restrict access at the directory or file level with the SET FILE command. For more information, see Section 4.3.5, Planning File and Directory Access Permissions, and Section 4.3.6, Specifying File and Directory Access Permissions.

4.1.4.1 Administrator Access

Server administrators can access all resources shared on a server, but only 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.4.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.4.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.4.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 security 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-4, Network Administrative Shares, lists some of the default shares created when the software is installed.

Table 4-4 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 directory tree containing the Advanced Server's data files. 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 hidden 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. Such connections allow access to all directories and files on the disk. Administrators working at remote servers or clients cannot make these 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.

When you create shares for directories using the ADMINISTER ADD SHARE command, you can specify any of the following for the device name in the share path:

• The autoshare name
• The physical device name
• An OpenVMS device logical name (search lists are not supported)

For more information, see Section 4.3.2, Creating a Share.

Note that when a logical name is specified 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.

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, see Section 6.1.4.2, The Advanced Server Common Event Log.)

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 device is listed in the NoAutoshare parameter, that device is not shared and cannot be accessed by the Advanced Server. Existing shares on the device are no longer accessible.
• If a device is listed in the Autoshare parameter, that device is shared and mapped to the specified autoshare name. If the length of the device volume label is 11 characters or less, the device will also be shared using the label name.
• If a device is not specified in either the NoAutoshare or Autoshare parameter, the Advanced Server creates a default autoshare using the volume label (as 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 create a disk administrative share, and the device is not accessible to the Advanced Server.

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

4.2.3.3 The Autoshare Parameter

The Autoshare value in the registry specifies an alias for the autoshare name created by default for an OpenVMS disk device. Advanced Server creates an autoshare for each mounted OpenVMS disk device when the server starts. To create a more meaningful share name or to map the device name to a DOS format, use the Autoshare value in the OpenVMS registry.

The format of the data associated with the Autoshare value is as follows, where devname_n is the device name (such as DUA2:), and sharename_n is the name of the autoshare:

devname_1=sharename_1, ..., devname_n=sharename_n

For example, the following command creates an autoshare named M$ for device DOT$DUA2:, and an autoshare named WORK5$ for device DOT$DUA3: (for more information about using REGUTL, see Section 7.2.4, Using the PWRK$REGUTL Utility to Manage Advanced Server Parameters in the OpenVMS Registry):

$ REGUTL SET VALUE * AUTOSHARE DOT$DUA2=M, DOT$DUA3=WORK5

The following command displays the autoshare values in the OpenVMS Registry:

$ REGUTL SHOW VALUE * AUTOSHARE Key: SYSTEM\CurrentControlSet\Services\AdvancedServer\ShareParameters Value: Autoshare Type: String Current Data: DOT$DUA2=M,DOT$DUA3=WORK5

As shown in the first command example above, when adding multiple entries, delimit each entry in the list with a comma. Note that the share name cannot exceed 11 characters. In addition, do not append a dollar sign ($) to the device name; the Advanced Server does this automatically.

Table 4-5, Sample Default Autoshare Names, shows physical device names and volume labels for disk devices mounted on node DOT and the autoshare names that the Advanced Server creates by default.

Table 4-5 Sample Default Autoshare Names

Device	Volume Label	Autoshare Name
DOT$DUA0:	AXPVMS072	AXPVMS072$
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.

For example, the data associated with the AutoShare value in the OpenVMS Registry appears as follows:

DOT$DUA2=M DOT$DUA3=WORK5

The Autoshare parameter directs the Advanced Server to create an autoshare named M$ for device DOT$DUA2: and an autoshare named WORK5$ for device DOT$DUA3:. If an administrator maps a network drive to the hidden share name M$, administrators connecting to M$ are accessing DOT$DUA2:[000000]. When you display the list of hidden shares, these autoshare names will also be listed. These autoshare names may also be used in share paths when creating directory shares.

As shown in Table 4-5, Sample Default Autoshare Names, the Advanced Server did not create an implicit autoshare for the device DOT$DUA3:, because the volume label WORK_DISK055 exceeds the 11-character limit. But Advanced Server allows you to include the device name (DOT$DUA3) in the autoshare list in the registry and creates the explicit autoshare WORK5$ for DOT$DUA3:.

4.2.3.4 The NoAutoshare Parameter

The NoAutoshare parameter specifies the OpenVMS device names that should not be automatically shared or available to the Advanced Server. If a device is listed in both the Autoshare list and the NoAutoshare list, the NoAutoshare definition takes precedence.

If the server configuration includes many disk devices, you may want to specify which devices are not shared automatically. By sharing some devices and not sharing others, you can separate OpenVMS disk resources from Advanced Server resources and reduce unnecessary resource consumption by the server.

The NoAutoshare parameter value is a comma-delimited list of implicit wildcard device references. For example, the following data associated with the NoAutoshare value in the OpenVMS Registry specifies search strings DFS*, DAD*, and PWRK$DKB1*:

DFS,DAD,PWRK$DKB1

With this data, any OpenVMS device names that begin with the strings DFS, DAD, or PWRK$DKB1 are not autoshared. If you want to exclude a specific device and negate the use of the wildcard, include the colon in the device specification. For example, the NoAutoshare value PWRK$DKB1: will always apply to a single device, while the value PWRK$DKB1 can apply to many devices, such as PWRK$DKB100:.

4.2.3.5 Sharing DECdfs Devices

DECdfs is a DECnet-based layered product that provides OpenVMS users with the ability to use remote disks as if they were directly attached to the local system. By default, Advanced Server does not automatically share devices managed by DECdfs. The OpenVMS registry contains the following default data associated with the NoAutoshare value:

DAD,_DFS

You cannot assign permissions to DECdfs devices; therefore, if you override the default and allow the Advanced Server to create an autoshare for a DECdfs device, users with user or operator privileges cannot access that device. Access to a shared DECdfs device is restricted to users in the Administrators group.

4.2.3.6 Autosharing in an OpenVMS Cluster Environment

OpenVMS disk devices mounted clusterwide are offered to users as shared devices (autoshares) by all server nodes in an OpenVMS Cluster system. Devices mounted on a specific server (not clusterwide) are accessible to users connected to that server only.

The OpenVMS Registry contains two types of values to define autoshares:

• Autoshare and NoAutoshare
• Autoshare_nodename and NoAutoshare_nodename

In an OpenVMS Cluster system, you can make a device available clusterwide by using the AutoShare value. You can restrict device availability using the NoAutoshare value.

In addition, you can control the devices to be automatically shared on a single node in the cluster, using the Autoshare_nodename and NoAutoshare_nodename values.

The following registry examples show how you can share disk devices in an OpenVMS Cluster. For this example, the cluster contains two members: DOT and TINMAN.

• On both DOT and TINMAN, the following value is defined:

  Key: SYSTEM\CurrentControlSet\Services\AdvancedServer\ShareParameters Value: Autoshare = PCS524$DKA100=J,PCS524$DKA200=K

• On the cluster member named DOT, the following value is defined:

  Key: SYSTEM\CurrentControlSet\Services\AdvancedServer\ShareParameters Value: Autoshare_DOT = DUA1001=H,DUA1002=G,DUA1006=I

• On the cluster member named TINMAN, the following value is defined:

  Key: SYSTEM\CurrentControlSet\Services\AdvancedServer\ShareParameters Value: Autoshare_TINMAN = DUA1001=H,DUA1002=G Key: SYSTEM\CurrentControlSet\Services\AdvancedServer\ShareParameters Value: NoAutoshare_TINMAN = DUA1006

In this example:

• PCS524$DKA100 and PCS524$DKA200 are available as shared devices on autoshares J: and K: on all OpenVMS Cluster server nodes.
• DUA1001 and DUA1002 are available as shared devices on autoshares H: and G: on server nodes DOT and TINMAN, respectively.
• DUA1006 is available as a shared device on autoshare I: on node DOT only.

The Advanced Server compares the clusterwide definitions with the node-specific definitions. If the same device is listed in both the clusterwide and node-specific Autoshare parameters, the clusterwide definition prevails. The NoAutoshare parameter uses the union of the clusterwide and node-specific autoshare lists.

	privacy and legal statement
6543PRO_010.HTML