SQL uses cross-reference files to keep track of database files and their
relationships. These files are collectively referred to as the SQL catalog. Public authority to the SQL catalog is *READ. This means that any user who has access to the SQL interface can display the names and text descriptions for all files on
your system. The SQL catalog does not affect the normal authority required to access the contents of database files.
Use care when employing a CL program that adopts authority to start SQL or Query Manager. Both of these query programs allow users to specify a file name.
Therefore, the user can access any file to which the adopted profile has authority.
Qshell
Qshell is a command environment based on POSIX and X/Open standards. It consists of two parts:
The shell interpreter (or qsh) is a program that reads commands from an input source, interprets each command, and then runs the command using the services of the operating system.
The utilities (or commands) are external programs that provide additional functions and can be simple or complex.
The Start QSH (STRQSH) command, also known as QSH, is a CL command that either starts a Qshell interactive session or runs a Qshell command. The QSH and STRQSH commands are delivered with public authority set to *USE.
For information about Qshell, see the iSeries Information Center at the following Web address and click the path Programming→ Shells and utilities→ Qshell:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp
i5/OS PASE
The QP2TERM program runs an interactive terminal session that starts a batch job to run an i5/OS Portable Application Solutions Environment (PASE) program.
This program uses the workstation display in the interactive terminal to present output and accept input for files stdin, stdout, and stderr in the batch job. The QP2TERM program, that runs an interactive terminal session, has the public authority set to *USE by default.
Most i5/OS PASE commands support the same options and provide the same behavior as AIX® commands, with some exceptions.
For information about i5/OS PASE, refer to the iSeries Information Center at the following Web address and select the path Programming→ Shells and utilities→ i5/OS PASE shells and utilities:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp
Note: When a Qshell interactive session is active, the QINACTITV system value is not in effect; that is the job does not time out.
4.4 Authorization lists
Authorization lists provide a convenient way of grouping users and authorities to resources. There are many advantages of authorization lists:
Securing a resource can authorize all the users on an authorization list to a resource in one operation.
Adding a user to an authorization list authorizes that user to all resources secured by the authorization list.
The restore of resources to the system where they were saved automatically attaches the resource to an authorization list.
Authorization lists reduce the number of authority entries, and the time to perform system back up is reduced.
An authorization list references both user profiles and the resources (objects).
These user profiles are authorized to the objects on the authorization list. The authorization list AUTL1, shown in Figure 4-8, has four user profiles and a
*PUBLIC authority of *EXCLUDE. The user profiles are authorized to the three objects secured by the list. The file NEWFILE is added to the authorization list.
Figure 4-8 Authorization list and objects
FILE_B PROG_D NEWFILE
BILL DEB HAKAN GRPPRF1
AUTL1
FILE_A
User List Mgt
*ALL
*CHANGE
*USE
*CHANGE
X X Authority
*PUBLIC *EXCLUDE
All user profiles on the authorization list are authorized to an object in one operation. The list of user profiles are authorized to the file NEWFILE by simply specifying the name of the authorization list (AUTL1) when the file is created.
This single operation requires less effort than authorizing the individual user profiles. The use of authorization lists, rather than individual user authorities, also improves the system backup time. A similar one-step operation can remove an authorization list from an object. This step, in effect, removes the authority to the object from all the user profiles on the authorization list.
Adding a user profile to an authorization list authorizes the user profile to all the objects secured by the authorization list. Adding the user profile NEWUSER to the authorization list AUTL1 gives this user profile authority to the objects FILE_A, FILE_B, PROG_D and (the new object) NEWFILE.
The user profiles in an authorization list can be individual user profiles or group profiles. In Figure 4-8, the profile GRPPRF1 is a group profile that has multiple members. Since the group profile is on the authorization list, each member of the group is authorized with *CHANGE authority. If profiles HAKAN, MIKE, SUSAN and TOM are the members of GRPPRF1, they have *CHANGE authority to the objects. When a user profile that is a member of the group is also on the
authorization list, the individual user profile authority is used instead of the group profile. Because the user profile HAKAN is authorized in the list AUTL1, the authority for user profile HAKAN is *USE.
4.4.1 Creating an authorization list
Authorization lists are created by the Create Authorization List (CRTAUTL) command. In our example, the authorization list AUTL1 is created with the following command:
CRTAUTL AUTL(AUTL1) AUT(*EXCLUDE) TEXT(‘Sample Authorization List’)
This command places the owner, BILL in this example, on the authorization list with *ALL and *AUTLMGT authority, as shown in Figure 4-8.
The AUT parameter of the CRTAUTL command defines the public authority on the authorization list. This public authorization list is used when the public authority on the object is specified as *AUTL and there is no authority for the user profile or the group profile for the user. When an object has public authority, the public authority on the authorization list is not used.
Important: An authorization list name must be unique.