IBM AS/400E manual User Authorities, User Identications UIDs, Group Identications GIDs

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 identi®cations (UIDs) for particular users, group identi®cations (GIDs) for groups of users, and supplemental GIDs, which list various group identi®cations 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 Identi®cations (UIDs)

A UID is a user identi®cation. 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 pro®le 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 different AS/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 Identi®cations (GIDs)

A GID is a group identi®cation. 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. A user pro®le 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 ®le or object if a particular UID does not have access authority to that ®le or

object. A GID never takes away authority from the user pro®le 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 on AS/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 pro®les 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

Chapter 9. Network File System Security Considerations 83