Previous | Contents | Index |
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:
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.
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
Advanced Server for OpenVMS supports the following OpenVMS file systems:
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:
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.
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 |
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:
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 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.
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 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 $ |
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:
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.
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:
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.
The autoshare name C$ is reserved. By default, Advanced Server defines C$ as an autoshare alias for PWRK$LMROOT:[000000]. If you define another volume as C$, the share name will be rejected. |
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
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 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.
Previous | Next | Contents | Index |