NFS has long had a tentative relationship to security. As with its cousin, CIFS/SMB (more commonly know as Windows File Sharing), security was not an area of primary focus. The elements of security that exist are significant, but they are nontrivial to implement, particularly across operating systems and with third-party applications.
In the past, customers who implemented NFS shares with Webdocs iSeries have lived with a single layer of security: IP address restriction. When a share is defined, rights are also defined for incoming requests. By default on most systems, the ALL_MACHINES class had Read authority to the share. This means that any machine on the network may mount the share and read its contents. Setting ALL_MACHINES to none and then giving read & write authority to a specific IP address (in this case, it would be the IP address of the LPAR that Webdocs iSeries is installed on) prevents machines at all other IP addresses (barring advanced spoofing attacks and the like) from mounting the share at all.
Likewise, on the IFS it had been routine to simply give *PUBLIC read, write and execute authority to the IFS folder that the share is mounted to. This folder was typically directly under the root folder, and would be called /RJSIMAGEDOCNFS or /WEBDOCSSHARE or similar. This practice is without consequence if IFS access is restricted to security officers, but in contexts where all general users have IFS access from the 5250 emulator or via a mapped drive on Windows, this became unacceptable. The practice we have been advocating recently has been to create a folder hierarchy. A parent folder is secured to only the required parties: typically the user created for RJS-related jobs and security officers. It’s child folder is then configured with *PUBLIC *RWX to allow for successful mounts. Users who do not have access to the parent cannot navigate, then, to the child.
There have been some instances, however, for which even these measures are not adequate. Whether it is the issue of IP address spoofing, or that of users with *IOSYSCFG mounting the share to folders they do have access to, there can be a need to tighten things further. This may be done with mapping User IDs. On Windows and UNIX-based operating systems, each user name has an associated number, known as the user ID or UID. The number schemes differ somewhat between Windows-based and UNIX-based operating systems, but if you are an administrator on the server and client machines, you can create a new user (or users) with the same UID, and then restrict access to a share to that user (or users). How this is done differs across operating systems.