There are some additional preparatory tasks that, while not essential to this effort, are strongly recommended. They involve cleaning up the UNIX/RACF environment and tightening security. These tasks mesh nicely with the other preparatory work:

• Eliminate Write (w) permission granted to OTHER. Access granted to OTHER is open to everyone. Write permission to a file lets anyone change the contents of the file. Write to a directory lets anyone create a file or sub-directory or delete an existing file or subdirectory. OTHER Write access to directories opens the door for users of the default user UID to create objects, which only exacerbates the replacement problem. You will need to log activity to analyze and design replacement access permissions, again using extended ACLs.
• Verify existing system IDs are still needed before assigning them UIDs.
• Verify user UNIX home directories are still needed and valid.
• Check the validity of SURROGAT BPX.SRV.userid profiles and their corresponding users.
• Confirm assignments of UID 0 (i.e., Superuser or ROOT authority) are appropriate.
• Verify UPDATE access permissions to FIELD class profiles governing OMVS UID and GID administration are appropriate.

Step 3: Decide How to Assign UIDs and GIDs

You have several options concerning the mechanics of how to assign UIDs and GIDs, including the use of newer features in RACF. Again, you will want to give this some thought before making assignments. To some extent, your choices will be influenced by the UID and GID numbering scheme you’ve chosen. Here are some considerations:

• Will you assign UIDs to all users or only to those using the default user? System Management Facility (SMF) data generated by RACF can tell you which users currently use the default user. If you plan to assign UIDs based on employee number, consider assigning all your employees a UID, regardless of whether they’re using UNIX services. The same may apply to process IDs to prevent failure due to lack of a UID. For customers, perhaps you will assign a UID only as needed.
• What methods will you use to assign UIDs and GIDs? Choices include manual entry, in-house developed automation, sequential assignment by RACF, and automatic assignment by RACF. Manual assignment may be best for process IDs. For employees, developing in-house software that cross-references HR and RACF and adds a UID based on employee number might be best. If certain sets of users and groups are simply to be assigned UIDs and GIDs sequentially in a specific range, the relatively new FACILITY class profile BPX.NEXT.USER can be implemented to define ranges that can be exploited by command keywords AUTOUID and AUTOGID. If you plan to assign UIDs and GIDs only as needed, the newest FACILITY class profile BPX.UNIQUE.USER can be defined to cause RACF to automatically create OMVS segments for users or groups upon their first use of UNIX services. You need not be locked into any one of these methods for all users. For one client, we’re employing a combination of all  these methods. BPX.NEXT.USER and BPX.UNIQUE.USER will automatically assign UIDs and GIDs to their 500,000 customer users on an as-needed basis.
• What will you do about existing users and groups with UIDs and GIDs that don’t conform to the new standard? For a critical process ID, perhaps it’s best just to make it an exception and leave its UID intact. If you decide to change any of them, you will need to change OWNERs and extend ACL entries on any files or directories they accessed under their prior UIDs or GIDs.

Note: FACILITY profile BPX.UNIQUE.USER must be used in combination with BPX.NEXT.USER. Defining UNIXPRIV SHARED.IDS is a prerequisite to defining BPX.NEXT.USER. They all require implementing the AIM database structure.


As with any major change to RACF, the final step is best done during a maintenance period when system activity is minimal. If you don’t plan to use profile BPX.UNIQUE.USER, confirm all users and groups using UNIX services have UIDs and GIDs and then simply delete BPX.DEFAULT.USER. If you plan to use BPX.UNIQUE.USER, confirm BPX.NEXT.USER is in place and functioning properly, then just define the profile. Once BPX.UNIQUE.USER is defined, RACF will immediately cease using BPX.DEFAULT.USER and begin automatically creating OMVS segments and assigning UIDs and GIDs sequentially.

You can retain the BPX.DEFAULT.USER profile until you’re confident BPX.UNIQUE.USER is functioning as intended. In either case, don’t delete the default user and default group referenced in BPX.DEFAULT.USER for a few weeks—just in case you need to reactivate use of BPX.DEFAULT.USER. Performing an Initial Program Load (IPL) of at least one system is advisable to ensure all goes well. Finally, a month or so after implementation, reorganize the RACF database. This will place all the new OMVS segments adjacent to their respective user and group records and let RACF retrieve them both more efficiently.


BPX.DEFAULT.USER is going away and there’s no stopping it. Weaning your system off its use can be a delicate matter, particularly if users have been creating and accessing UNIX files and directories using the default user or default group. This is especially true if some of those users are critical started tasks or process IDs. Don’t wait until the eve of your upgrade to a release of z/OS beyond 1.13 to address this issue. The process of examining and updating permissions in all your UNIX file systems is almost certain to take much more time and effort than you might anticipate. Act now!


2 Pages