|
HP OpenVMS Systems Documentation |
|
HP TCP/IP Services for OpenVMS
|
| Previous | Contents | Index |
The server uses the following database files to grant access to users on client hosts:
These database files are usually created by TCPIP$CONFIG and can be shared by all OpenVMS Cluster nodes running TCP/IP Services. To control access to these database files, set the OpenVMS file protections accordingly. By default, World access is denied.
Section 22.6 describes how to create these database files on your
server.
22.1.4 How the Server Maps User Identities
Both OpenVMS and UNIX based systems use identification codes as a general method of resource protection and access control. Just as OpenVMS employs user names and UICs for identification, UNIX identifies users with a user name and a user identifier (UID) and one or more group identifiers (GIDs). Both UIDs and UICs identify a user on a system.
The proxy database contains entries for each user who accesses a file system on your local server. Each entry contains the OpenVMS user name, the UID/GID pair that identifies the user's account on the client system, and the name of the client host. This file is loaded into dynamic memory when the server starts.
When a user on the OpenVMS client host requests access to a file, the client searches its proxy database for an entry that maps the requester's identity to a corresponding UID/GID pair. (Proxy lookup is performed only on OpenVMS servers; UNIX clients already know the user by its UID/GID pair.) If the client finds a match, it sends a message to the server that contains the following:
The server searches its proxy database for an entry that corresponds to the requester's UID/GID pair. If the UID maps to an OpenVMS account, the server grants access to the file system according to the privileges set for that account.
In the following example, the proxy entry maps a client user with UID=15/GID=15, to the OpenVMS account named ACCOUNT2. Any files owned by user ACCOUNT2 are deemed to be also owned by user UID=15 and GID=15.
OpenVMS User_name Type User_ID Group_ID Host_name ACCOUNT2 OND 15 15 * |
After the OpenVMS identity is resolved, the NFS server uses this
acquired identity for all data access, as described in Section 22.1.7.
22.1.5 Mapping the Default User
In a trusted environment, you may want the server to grant restricted access even if the incoming UID does not map to an OpenVMS account. This is accomplished by adding a proxy entry for the default user. The NFS server defines the default user at startup with the following attributes:
You can initialize these attributes using the SYSCONFIG command, which is defined by the SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM procedure. For example:
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS $ SYSCONFIG -r nfs_server noproxy_uid=-2 noproxy_gid=-2 |
If the server finds a proxy entry for the default user, it grants access to OpenVMS files as the OpenVMS user associated with "nobody" in the proxy record. TCP/IP Services normally uses the UNIX user "nobody" (--2/--2) as the default user.
To temporarily modify run-time values for the default user, use the /UID_DEFAULT and /GID_DEFAULT qualifiers to the SET NFS_SERVER command.
To permanently modify these values, edit the SYS$STARTUP:TCPIP$NFS_SYSTARTUP.COM file with the commands to define new values for the UID and GID logical names. See Section 22.12 for instructions on modifying SYSCONFIG variables to change the default values.
If you require tighter restrictions, you can disable the default user mapping and set additional security controls by setting the attribute noproxy_enabled . See Section 22.11 for more information.
The configuration procedure for the NFS client creates a nonprivileged account with the user name TCPIP$NOBODY. You may want to add a proxy record for the default user that maps to the TCPIP$NOBODY account. |
When a remote UNIX client does a mount, it is often performed by the superuser. (In some UNIX implementations, this can be performed only by the superuser.)
A superuser (root) on a remote client does not automatically become a privileged user on the server. Instead, the superuser (UID=0) is mapped to the default user defined with the attributes noproxy_uid and noproxy_gid . (By default, user "nobody" (--2/--2) is used.)
You may have remote clients that use the superuser to mount file
systems. If you want to grant normal root permissions, add a proxy
record with UID=0/GID=1 and map this to an appropriate OpenVMS account.
The ability of the remote superuser to mount and access files on the
server is controlled by the privileges you grant for this OpenVMS
account.
22.1.7 How OpenVMS and the NFS Server Grant File Access
To protect your exported file systems, you must take care when granting account and system privileges for remote users. You must also understand how OpenVMS grants access to files.
The NFS server uses the proxy database to map the incoming user identity to an OpenVMS account. The server uses the account's UIC to evaluate the protection code, along with other security components, before granting or denying access to files.
If the proxy account has an access control entry (ACE) that denies or grants access, the NFS server honors that. However, access checking by the client can make such ACEs ineffective.
For a more thorough discussion on access checking, refer to the
OpenVMS Guide to System Security.
22.1.8 Understanding the Client's Role in Granting Access
Before sending a user request to the NFS server, the client performs its own access checks. This check occurs on the client host and causes the client to grant or deny access to data. This means that even though the server may grant access, the client may deny access before the user's request is even sent to the server host. If the client user maps to an OpenVMS account that is not allowed access to a file, an ACL entry may not allow access from an NFS client as it would locally for that OpenVMS account.
With this variable set, the TCP/IP Services startup procedure creates the
TCPIP$NFS_REMOTE identifier. For example, you can use this identifier
in the ACL to reject access to some (or all) files available through
NFS. (See Section 22.12 for more information about logical names.)
22.1.9 Granting Access to PC-NFS Clients
TCP/IP Services provides authentication services to PC-NFS clients by means of PC-NFS. As with any NFS client, users must have a valid account on the NFS server host, and user identities must be registered in the proxy database.
Because PC operating systems do not identify users with UID/GID pairs, these pairs must be assigned to users. PC-NFS assigns UID/GID pairs based on information you supply in the proxy database.
The following describes this assignment sequence:
The NFS server can be shut down and started independently. This is useful when you change parameters or logical names that require the service to be restarted.
The following files are provided:
To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:
If the NFS server resides on more than one host in an OpenVMS Cluster system, you can manage the proxy database and the export database as a homogeneous OpenVMS Cluster system (one proxy file on the OpenVMS Cluster system) or a heterogeneous OpenVMS Cluster system (a different proxy database on each host in the cluster).
The NFS server automatically responds to the requests it receives on any TCP/IP network interface. Therefore, if several OpenVMS Cluster nodes have Internet cluster interfaces, the server can execute as a clusterwide application. Clients that mount file systems using the ARP-based cluster alias can then be served by any of the NFS servers in the cluster. Because NFS uses cluster failover, if one of the servers is taken down, client requests are redirected to another host in the cluster.
To allow NFS clients to access the cluster, define an ARP-based cluster alias (as described in Section 1.4.1), and a network interface name for each cluster member.
Do not use a DNS-based cluster alias for this purpose. |
If you plan to export file systems to PC-NFS client hosts, you must enable PC-NFS using TCPIP$CONFIG. The PC-NFS process starts automatically.
You can also use the following commands to manage PC-NFS:
For information about setting up PC-NFS for printing, see Chapter 26.
22.5 Managing the MOUNT Service
The MOUNT service responds to Version 1 of the MOUNT protocol, which is used with Version 2 of the NFS protocol. It also supports Version 3 of the MOUNT protocol, which is used with Version 3 of the NFS protocol.
The MOUNT service is started automatically when you start the NFS server (for example, using TCPIP$NFS_SERVER_STARTUP.COM).
You can customize the operation of the MOUNT service by using SYSCONFIG to modify the attributes listed in Table 22-1.
| Attribute | Description |
|---|---|
| mountd_option_a |
Verifies the Internet addresses of hosts that make mount and unmount
requests. If a client's address cannot be translated into a host name
by the
gethostbyaddr()
function and is then translated back into the same Internet address by
the
gethost-byname()
function, the request is rejected.
Requires name resolution to be enabled. |
| mountd_option_d | Turns on Internet address verification and domain checking. If you are running the BIND service, MOUNT verifies that a host making a mount or unmount request is in the server's domain. |
| mountd_option_i |
Verifies the Internet address of hosts that make mount and unmount
requests. If a client's address cannot be translated into a host name
by the
gethostbyaddr()
function, the request is rejected.
Requires name resolution to be enabled. If the mountd_option_i attribute is not set, and a client's address cannot be translated, the address is converted to a string in the form xx.xx.xx.xx. This allows users to access exported file systems that have a wildcard (*) (allow everybody) as their host list. The mountd_option_i attribute is automatically enabled when either the mountd_option_d or the mountd_option_s attribute is specified. |
| mountd_option_n |
Allows nonroot mount requests to be served. In previous versions of
TCP/IP Services, the servicing of nonroot mount requests was allowed by
default. With this version, this attribute must be set to allow nonroot
mount requests.
Specify this attribute only if there are clients (such as desktop computers) that require it. |
| mountd_option_s | Turns on Internet address verification and subdomain checking. If you are running the BIND service, the MOUNT service verifies that a host making a mount or unmount request is in the server's domain or subdomain. |
See Section 22.12 for information about using the SYSCONFIG command.
22.6 Registering Users and Hosts
In a NFS environment shared by UNIX hosts, a common user authorization domain may be used. In this configuration, each user's UID is unique for all the hosts. On OpenVMS, however, the user authorization file (UAF) cannot be shared, but client user identifiers must be mapped to OpenVMS accounts. Therefore, users on client hosts must have corresponding OpenVMS accounts on the OpenVMS NFS server.
To establish this common allocation on OpenVMS, each client UID must be mapped to a unique OpenVMS account. This arrangement requires a separate OpenVMS account for each NFS client. It is possible to use the same OpenVMS account for multiple users, but this is not recommended for accounts in which users have read or edit access to files.
After setting up appropriate accounts, you must register users in the
proxy database and set mount points in the export database.
22.6.1 Adding Proxy Entries
Each user accessing your local server must be registered in the proxy database. See Section 22.1.3 if you are not familar with how the server uses this database to grant access to remote users. You should create the proxy database before the NFS server starts. If you are adding proxies, create the OpenVMS accounts before creating the proxy entries.
An empty proxy database file, TCPIP$PROXY.DAT, is created for you when you first use the TCPIP$CONFIG configuration procedure to configure NFS. This file is empty until you populate it with proxy entries for each NFS user. If you do not use TCPIP$CONFIG to configure NFS, use the CREATE PROXY command to create the empty database file. The file TCPIP$PROXY.DAT resides in the SYS$COMMON:[SYSEXE] directory.
Use the ADD PROXY, REMOVE PROXY, and SHOW PROXY commands to maintain the proxy database. Enter these commands at the TCPIP prompt:
TCPIP> ADD PROXY user_name /UID=nn /GID=nn /HOST=host_name |
For example, you can use the following command to register a user:
TCPIP> ADD PROXY SMITH /UID=53 /GID=45 /HOST="june" |
You can specify a list of hosts for which the UID and GID are valid. For example:
TCPIP> ADD PROXY SMITH /UID=53 /GID=45 /HOST=("APRIL","MAY","JUNE")
|
You can also specify that all hosts are valid using an asterisk (*) wildcard character. For example:
TCPIP> ADD PROXY SMITH /UID=53 /GID=45 /HOST=* |
If you use the configuration procedure to configure NFS, the export database is created for you, if it does not already exist. This file is empty until you populate it with mount point entries. If you do not use TCPIP$CONFIG to configure NFS, use the CREATE EXPORT command to create the empty database file.
Use the ADD EXPORT, REMOVE EXPORT, and SHOW EXPORT commands to maintain the export database. Enter these commands at the TCPIP prompt:
TCPIP> ADD EXPORT "/path/name" /HOST=host_name |
See the HP TCP/IP Services for OpenVMS Management Command Reference manual for more information about these commands and command qualifiers.
You can identify mount points by any of the following methods:
You can back up NFS-mounted files using standard OpenVMS backup procedures. For more information, see the OpenVMS documentation.
If you back up an OpenVMS file system or a container file system while remote users are accessing the files, the resulting save set may contain files that are in an inconsistent state. For a container file system, there is the additional danger that the container file itself may be in an inconsistent state.
Furthermore, the OpenVMS Backup utility does not issue warning messages when backing up files that are opened by the NFS server, even when the /IGNORE=INTERLOCK qualifier to the BACKUP command was not used.
The approach to backing up is to schedule the backup for a time when users will not be accessing the files. Then either unmap the file systems to be backed up or shut down the NFS server.
If you perform an incremental backup (using the /SINCE=MODIFIED
qualifier to the BACKUP command) on container file systems, a separate
copy of the container must also be backed up because the container
file's modification date never changes. See Section 22.9 for
information about setting up container file systems; see Section 22.10
for information about managing container file systems.
22.8 Setting Up and Exporting an OpenVMS File System
The following example describes how to set up an OpenVMS file system on the OpenVMS server and how to make the file system available to Joe Brown, a user on UNIX client ultra .
Joe Brown has an OpenVMS user name of BROWN and a UNIX user name of joe .
% grep joe /etc/passwd joe: (encrypted password) :27:58: ... |
$ TCPIP TCPIP> ADD PROXY BROWN /UID=27 /GID=58 /HOST=ultra TCPIP> MAP "/vmsdisk" DSA301: TCPIP> ADD EXPORT "/vmsdisk/brown/test" /HOST=ultra |
If users need to create files with case-sensitive names or names containing characters that do not conform to the OpenVMS syntax, you can enable name conversion, which gives users more file-naming flexibility without creating a container file system. Use the /OPTIONS=NAME_CONVERSION qualifier to the command ADD EXPORT to enable this option.
With the NAME_CONVERSION option set, users can create files and directories in an OpenVMS file system using names that do not conform to OpenVMS file-naming rules.
If any client hosts had the file system mounted before the name conversion was enabled, they must dismount and remount for this feature to take effect. |
For more information about file name conversion, see Appendix C.
| Previous | Next | Contents | Index |