User Authorities
As users log on to NFS clients and servers, the user authority of each user dictates
what they can and cannot do. User authorities are assigned to users by
administrators, and usually take the form of user identifications (UIDs) for particular
users, group identifications (GIDs) for groups of users, and supplemental GIDs,
which list various group identifications that a user belongs to.
Properly assigning user authorities for users and systems can help you to construct
a secure, efficient namespace. Users will always have access to the right data
when they need it. Improperly assigning user and system authorities will lead to an
insecure namespace with major internal and external security breaches.
User Identifications (UIDs)
A UID is a user identification. UIDs are made up of a number that represents the
user on a particular system. The UID does not include a user’s name or any other
information about the user at all. UIDs are simply a way for the system to recognize
users and activate their user profile for use with authorization checking. Users may
have access to a various number of systems, so they could maintain a number of
different UIDs and associated authorities across those systems. Users should only
ever have the access authority that they need, and no more.
For example, on one AS/400, Bill might have a UID of 136. On a differentAS/400
his UID could be 142. On yet another, Bill might have a UID of 2700.All of these
UIDs could potentially carry with them a number of different authorities on each
network system. Bill could have *USER authority on one system and *QSECOFR
authority on the next, and so on. The improper administration of such varied UIDs
that can lead to NFS security hazards.
Group Identifications (GIDs)
A GID is a group identification. It operates in the same fashion as a UID as a way
of identifying a user’s access on a given system. The GID goes one step further,
however, by acting as a general authority for a group of users or machines. GIDs
are not at all relative to UIDs and do not correspond with UIDs. Auser profile may
or may not have a GID associated with it.
GIDs, therefore, might function for a department in a company or for a set of
workstations in a computer lab. GIDs can function as a second method of access to
a given file or object if a particular UID does not have access authority to that file or
object. A GID
never
takes away authority from the user profile associated with it;
GIDs can only

add

authority. If a GID exists on the server that matches the request
of a client, then the associated authority is added to the request. If the GID does
not exist on the server, then the GID is ignored.
There are also supplemental GIDs, which can act as a third or fourth or

nth

method
of access authority to an object. GIDs are assigned to users based on what groups
a user in question belongs to. UNIX servers and clients can use supplemental GIDs
to determine the authority of a user. The Network File System onAS/400 supports
supplemental GIDs. If a user on the client system is a member of multiple groups,
then the system sends the GIDs for those groups to the server. The server will use
those GIDs that have existing group profiles as the list of supplemental GIDs for the
mapped NFS user on the server. Because GIDs and supplemental GIDs add to a
user’s authority, GIDs may allow users to access objects that are ordinarily
Chapter9. Network File System Security Considerations 83
|
|
|
|
|
|
|
|
|