Technical data

NFS Client
21.1 Key Concepts
21.1.4 How the Client 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 group identifier (GID) pair. Both UIDs and GIDs are
used to identify a user on a system.
The proxy database contains entries for each user wanting to access files on a
server host. Each entry contains the user’s local OpenVMS account name, the
UID/GID pair that identifies the user’s account on the server system, and the
name of the server host. This file is loaded into dynamic memory when the NFS
client starts. Whenever you modify the UID/GID to UIC mapping, you must
restart the NFS client software by dismounting and remounting all the client
devices. (Proxy mapping always occurs even when operating in OpenVMS to
OpenVMS mode.)
The only permission required by the UNIX file system for deleting a file is write
access to the last directory in the path specification.
You can print a file that is located on a DNFSn: device. However, the print
symbiont, which runs as user SYSTEM, opens the file only if it is world readable
or if there is an entry in the proxy database that allows read access to user
SYSTEM.
21.1.4.1 Default User
You can associate a client device with a default user by designating the user with
the /UID and /GID qualifiers to the MOUNT command. If you do not specify a
user with the /UID and /GID qualifiers, NFS uses the default user –2/–2. If the
local user or the NFS client has no proxy for the host serving a DNFS device, all
operations performed by that user on that device are seen as coming from the
default user (–2/–2).
To provide universal access to world-readable files, you can use the default UID
instead of creating a proxy entry for every NFS client user.
Compaq strongly recommends that, for any other purposes, you provide a
proxy with a unique UID for every client user. Otherwise, client users may
see unpredictable and confusing results when they try to create files.
21.1.5 How the Client Maps UNIX Permissions to OpenVMS Protections
Both OpenVMS and UNIX based systems use a protection mask that defines
categories assigned to a file and the type of access granted to each category.
The NFS server file protection categories, like those on UNIX systems, include:
user, group and other , each having read ( r ), write ( w ), or execute ( x ) access.
The OpenVMS categories are SYSTEM, OWNER, GROUP, and WORLD. Each
category can have up to four types of access: read (R), write, (W), execute (E), and
delete (D). The NFS client handles file protection mapping from server to client.
OpenVMS delete access does not directly translate to a UNIX protection category.
A UNIX user can delete a file as long as he or she has write access to the parent
directory. The user can see whether or not he or she has permissions to delete a
file by looking at the protections on the parent directory. This design corresponds
to OpenVMS where the absence of write access to the parent directory prevents
users from deleting files, even when protections on the file itself appear to allow
delete access. For this reason, the NFS client always displays the protection
mask of remote UNIX files as permitting delete access for all categories of users.
21–4 NFS Client