Although all the privileged instructions and all the special authorities can be individually specified in the user profile, OS/400 combines instructions and authorities into six groups. These are

•  All object special authority — Allows access to any system resource, whether or not the user has any private authority to the resource.

•  Security administrator special authority — Allows the user to create and change user profiles if authorized to the commands to create and change the user profile.

•  Save system special authority — Allows the user to save, restore, and free storage for all objects on the system, whether or not the user has object existence authority for the objects.

•  Job control special authority — Allows the user to change, display, hold, release, cancel, and clear all jobs that are executing on the system or are on job queues or output queues.

•  Service special authority — Allows the user to perform Display/Alter/Dump service operations.

•  Spool control special authority — Allows the user to delete, display, hold and release spool files owned by other users.

The user profile is the heart of the security system on an AS/400, controlling access to just about every resource in the system. Even though a user’s profile may not provide the authority to some resource or object in the system, the user may be able to obtain the authority in other ways. In the following sections, we look at the two ways to gain additional authority: program adoption of authority and group authorities.

Program Adoption of Authority

While a program is executing, the user profile that owns the program can serve as another source of authority. This capability to adopt authority allows a program to perform operations that require an authority the user does not have directly. Rather than granting additional authority to a user, the user’s application program calls another program whose owner has the authority to perform the operation. Thus, program adoption of authority requires the concept of a call stack. When a program adopts the authority of the called program’s owner, it is always additive; adoption never decreases authority.

Adoption is a program attribute specified at the time a program is created. If a called program is identified as one that allows adoption of authority, any calling program can use the owner’s authority while the called program is running. A program can specify no adoption, but only if it executes in system state. A program also can specify no propagation. This indicates that the calling program will adopt while executing, but programs farther down the call chain will not keep the authority.

So far, we have discussed only a single user having authority to a single object. There are times, however, when we want to give the same authorities to a group of users. And there are other times when we want to give a user authority to a group of objects. We next look at grouping authority.

Grouping Authority

Three methods for grouping authorities are available on the AS/400. Authorization lists and group profiles simplify the administration of AS/400 security. These two approaches eliminate the need to separately grant authorities when several objects or several users have the same authorities. IBM introduced authority holders for the System/36 Environment.

An authorization list enables the authorization of multiple objects to multiple users. In addition, each user can have a different level of authority for all the objects in the list. Figure 7.1 shows an authorization list with three users and three objects. Each of the three users has authority to all the objects on the list; but in our example, each user has a different authority. To add, remove, or change users and their authority on the list requires the authority list management previously described. At the MI, the authorization list is implemented as a system object.

Figure 7.1  Authority List Example

Group profiles allow users to share a common profile in addition to having their own user profile. Users who are members of a group, such as a department in a business, can share common objects. The authorization of all members in the group can be managed by authorizing the group profile.

Access to the group profile is through the individual user’s profile. If an individual user profile has authorization to an object, that private authority overrides the authority of the group profile. This characteristic allows specific group members to be given either more or less authority than other members of the group.

A user profile can be a member of up to 16 group profiles. One of these groups can be identified as the primary group. The reason for having a primary group is to speed up the authority search algorithm, which we examine in the following section. The primary group authority for an object is stored in the object itself, whereas authorities for the other groups are stored in their group profiles. Performance can be improved when a primary group is used, because the search algorithm does not have to retrieve the group profile; it just looks in the object.

System/36 applications have the capability to authorize users to a file that doesn’t exist. Authorization can be given before the file is created. The application in the System/36 can even continue to have authority to the file after the file has been deleted. Within a System/38, there was no such concept. Authorization could not be granted until the object had been created. Also, if an object in a System/38 was deleted, all records of authority to the object were removed from the system.

For the System/36 Environment on the AS/400, authority holders were added to support authorization to nonexistent files. The use of authority holders, which is required only for migration, is limited to certain types of program-described files; authority holders are not supported for other types of files and objects. Because of this, neither OS/400 nor the MI has an authority-holder object.