1. Administrators should
never
export the “root” (/) Directory. Remember that
whenever you export a file system, you also export all of the directories and
objects “downstream” of the path. Should the “root” (/) directory become
exported, all the other directories and objects downstream of “root” (/) will
become exported as well. Export only what is needed by clients.
2. Administrators should
never
export any file system to “the world,” allowing
universal client access to information. Instead, administrators should tailor each
exported file system to the needs of each client. Opening up the server to
access from “the world” allows for unknown users to mount and change your
files at will. Export only to specific clients.
See “Exporting to ″The World″” on page89 for more information about limiting
your exports.
3. Administrators should
very cautiously
give QNFSANON universal access to any
file system whatsoever. Doing so allows unknown (anonymous) users to mount
and change file systems. Export only to clients who need file systems.
See “Anonymous Users” for more information about limiting access to
anonymous users.
Export Options
There are two major ways to export a file
insecurely
to the network namespace:
1. Administrators can give anonymous users access to exported file systems by
allowing unknown users to read and make changes to data.
2. Administrators can export to “the world,” meaning that all those users both
within and outside of the trusted community can access the exported data.
It is not necessary to distribute file systems to unknown users or systems not in the
trusted community.The administrator of an NFS server should only ever export the
proper data for the proper clients at any given time.

Anonymous Users

Toprohibit anonymous users from gaining access to exported file systems, it is
important to completely understand the ANON option of the CHGNFSEXP
command. Youcan specify that anonymous or unknown UIDs be mapped to the
QNFSANON UID, giving those users a level of access on AS/400.
Toprevent this from occurring, an administrator can specify ANON=-1 to prohibit
anonymous users from mapping to QNFSANON on the system. Remember that the
default option value is QNFSANON, which translates to giving anonymous users
*USER authority.This will allow anonymous users to read files, but not write to
them. Administrators can also specify a UID with a different default authority with
this option.
When users are mapped to QNFSANON, any objects they create belong to that
profile, and
not
to their user profile. For example, a user named Cayce has a UID of
123 and mounts a server file system on a client. Cayce then creates a file. The
owner of this file is QNFSANON,
not
Cayce. Adisplay of the permissions reveals
the read, write, and execute authorities belong only to the owning profile,
QNFSANON. Cayce has no access to the file he just created because he is not the
owner.
The solution to this problem is to follow one of these procedures:
vCreate the file with open permissions for “the world”
88 OS/400 Network File System Support V4R4