IBM AS/400E manual Proper UID Mapping

There are other ways to tap into a system of users and the objects owned by them. The administrator of a client can deliberately impersonate a remote server UID.

For example, the administrator of a client can log on and access the UID of a user, Mary on TULAB2, who accesses the client. If the UID of Mary is 123, then the client administrator can assume this UID and, in effect, become Mary on both systems.

There exists on TULAB2 a ®le named/home/mary/index.html. Before any users perform actions on this ®le, they must have its ®le handle. Users with proper

authorities can get this handle by making a request to the parent directory. The parent directory of /home/mary/index.html is /home/mary. A ®le handle is a unique

identi®er of an object that describes the object without ever changing. A ®le handle will last through multiple IPLs, crashes, and so on.

If the client administrator successfully impersonates Mary with a UID of 123, then the administrator can gain access to ®le handles. The client administrator would then have the ability to read, write, change, and delete Mary's ®les.

The solution in this case is for namespace administrators to follow the rules of proper and appropriate UID mapping across the namespace. Administrators also need to pay attention to how they export ®le systems. The trusted community should not be opened up to outside clients or anonymous users who request access.

Proper UID Mapping

An administrator needs to properly map UIDs to provide a secure namespace where users have access to the appropriate information on the appropriate systems. There is a step-by-step process for doing this one user and system at a time.

For example, a user named Joan has a UID of 27 on TULAB1 and a UID of 14 on TULAB2. Chris Admin feels that these UIDS should be the same across the two systems to provide matching pro®les that he has set up. If Joan owns any objects within the integrated ®le system, then Chris Admin cannot change her UID on TULAB2. He performs this series of events:

1.Chris Admin chooses one UID number for Joan's universal Network File System UID. This number will be Joan's UID across the entire network namespace. In this case, Chris decodes that JOAN=27.

2.He creates the temporary UID of TEMP=27 on TULAB2. If this UID is not already in use and processes correctly, then Chris Admin continues with the process.

3.He uses the CHGUSRPRF (Change User Pro®le) command to change the UID of TEMP to any unused number (12345).

4.Chris Admin then uses the DLTUSRPRF (Delete User Pro®le) command to delete all of Joan's directories and objects from TULAB2. Before he completes this command, however, he uses an option to transfer ownership of all these objects to TEMP.

5.He then uses the CRTUSRPRF (Create User Pro®le) command to create JOAN=27 on TULAB2.

6.Chris Admin uses the DLTUSRPRF command once again to delete the TEMP user pro®le and restore ownership of all objects back to Joan, whose universal NFS UID is now 27.

86OS/400 Network File System Support V4R4