Chapter 13: Elements of Security and Configuration

System security is a very serious matter. When security is well implemented, your system is relatively safe from sabotage—intentional or not. Security prevents unauthorized users from becoming privy to information such as employee records, financial statements, or manufacturing data. Security is a complex topic that deserves a whole book in itself. This chapter contains only basic information and doesn't attempt to paint a complete picture. You should refer to the i5's Security Concepts and Planning Guide for a more extensive treatment of the matter.


Under i5/OS, security is based on the concept of authority. Authority links an object (such as a file or a program) to a user (such as yourself or QSYSOPR). The authority determines whether the user has access, and if so, what kind of access, to the object. For example, if you have a file named EMPLOYEES in a given library, you can instruct the system to allow user JOSIE (who manages the Personnel department) full access to it. JOSIE would then be able to read EMPLOYEES, update it, delete records, reorganize the records, and perform all other operations to the file. At the same time, user PETER could be given only enough authority to read EMPLOYEES, but make no changes. If PETER runs a program that attempts to add a new employee to the file, the program ends with an error. You can also specify that all other users should have no authority at all. In this case, user STEVE can neither read nor update the file. Table 13.1 shows a brief summary of all the object authorities you can use:

Table 13.1: Object Authorities.




Object Operational. Allows the user to operate the object according to the data authorities that may be given (*READ, *ADD, *UPD, and *DLT). It also allows the user to look at the description of the object.


Object Management. Allows the user to manage the object; i.e., to maintain security for the object, move it to another library (MOVOBJ), or rename it (RNMOBJ). If the object is a database file, the user can also add members to it (ADDPFM, ADDLFM).


Object Existence. Allows the user to control the existence of the object and who should be its owner. The user can run the following commands on the object: DLTXXX, SAVOBJ with STG(*FREE), SAVOBJ, RSTOBJ, and CHGOBJOWN. Note that if the user already has *SAVSYS special authority (defined later), the user doesn't need *OBJEXIST to save or restore any objects.


Controls who can alter the attributes of database files and SQL packages, such as maintaining triggers, referential integrity, or other attributes.


Used only for database files. It authorizes the user to reference an object from another.


Allows maintenance of an authorization list (a list of authorities that apply to a set of objects).


Data authority required to display the contents of an object. For a database file, *READ is required to read records.


Data authority required to add entries to an object. For a database file, *ADD is required to write new records.


Data authority required to change entries in an object. For a database file, *UPD is required to update existing records.


Data authority required to remove entries from an object. For a database file, *DLT is required to delete existing records


Allows the user to locate an object in a library, and to run a program.

For your convenience, you can also use standard combinations provided by IBM. The combinations in Table 13.2 can come in handy:

Table 13.2: Combined Authority Options.




Equivalent to all object authorities together: *OBJOPR, *OBJMGT, *OBJEXIST, *OBJALTER, *OBJREF, *READ, *ADD, *UPD, *DLT, and *EXECUTE. The user can do anything with the object, except whatever can only be done by the object's owner or controlled by an authorization list. When a user creates an object, that user automatically acquires *ALL authority to the object.


Equivalent to *OBJOPR, *READ, *ADD, *UPD, *DLT, and *EXECUTE.


Equivalent to *OBJOPR, *READ, and *EXECUTE.


No authorities whatsoever. The user can't do anything with the object, not even look at it.

Private Authorities

Authorities can be assigned to specific users. For example, the security administrator can give user CHARLIE enough authority to *READ the inventory master file, without allowing him to change or delete existing records or add new ones. This is called a private authority because it applies to one user.

Private authorities are given by entering an actual user profile name (such as CHARLIE).

Public Authorities

In contrast with private authorities, public authorities are those given to the users in general. When an object such as a file is created, the creator (or the security administrator) decides what authority to give the public. Usually (although not necessarily), this authority is *CHANGE, which means that the user can read, update, or delete records from the file.

When the security administrator begins assigning private authorities to individual users, these private authorities override the public authority; they become exceptions to the rule.

For example, a programmer creates a file named ORDERS and gives the public *CHANGE authority. Then the security administrator grants user FRED *READ authority, and user FRANK *EXCLUDE authority.

When user JEREMY signs on, he has *CHANGE authority because he has not been given any private authority to file ORDERS, so he enjoys the public's authority. When user FRANK signs on, he has *EXCLUDE authority because the security administrator specifically gave him that authority.

Special Authorities

Special authorities are different from private and public authorities. Special authorities give the user authorization to perform certain system-related functions, while private and public authorities give the user authorization to manipulate objects.

The special authorities are listed in Table 13.3. Users can have one or more of them in any combination; they also can have none at all.

Table 13.3: Special Authorities.

Special Authority



Save System. Gives the user authorization to perform any save or restore operation, even on objects to which the user is not authorized through private or public authorities. For example, a system operator may not be authorized to read the Employee master file, but with *SAVSYS authority, the system operator can perform all the necessary save and restore operations to have a proper backup.


Job Control. Gives the user authorization to maintain other user's jobs. System operators need this special authority. The user can display or change all jobs, and manipulate all printed output if the reports are in output queues that have OPRCTL(*YES). *JOBCTL also gives the user the authorization to reload the operating system, perform an IPL, and control printer writers and subsystems.


All Objects. Gives the user authority to perform any operation on any object. This special authority overrides all private and public authorities on the system, so you must make sure which users really need it. Once they have *ALLOBJ, users can read, change, or delete any file; execute any program or command; add, update, and delete records from any file; etc. Do not give *ALLOBJ authority unnecessarily.


Security Administrator. Gives the user authority to maintain user profiles if the user has private/public authority to the Create, Change, and Delete User Profile commands (CRTUSRPRF, CHGUSRPRF, and DLTUSRPRF), and private/public authority to the user profile object (*USRPRF) being maintained. The user also can only grant those special authorities the user has. Therefore, a security administrator who doesn't have *ALLJOB cannot give *ALLJOB to another user.


Service. Gives a user the authority to run the service functions, such as the System

Service Tools (SST). Do not give *SERVICE special authority to anyone without first determining that the user really needs it to fulfill his duties. Only key system operators should have *SERVICE authority.


Spool Control. Gives the user the authority to control printed output in any output queue. Before you decide to give *SPLCTL to a user, think about confidential reports waiting in output queues. A user with *SPLCTL authority is able to display them.


Auditing. Gives the user the necessary authority to perform auditing functions such as changing QAUDXXX system values and changing user profile or object auditing.


Gives the user authorization to configure communications and input/output devices.


Do not give your users more authority than they need to perform their jobs. Although it would simplify your job to give every user *ALLOBJ special authority, for example, it also would completely negate security level 30 and provide open doors everywhere.

Security Levels

The i5/OS provides five levels of security called 10, 20, 30, 40, and 50 in order of increasing security.

Level 10 security is no longer supported. It really supplied no security at all, not even password security.

Level 20 requires a user name and password to sign on. Both are checked for accuracy, and the correct password must be entered for the right user profile name. However, once you pass the sign-on display barrier, the system imposes no other obstacles on you. You can do anything you want, and so can anyone else who signs on successfully. Any user can create or change other users, configure the system, or gain access to all database files.

Level 20 is better than 10, but still is not enough security in most cases. Level 20 is acceptable for installations where users are never given a chance to enter commands but are forced to select options from a menu, which has been designed so that it contains only the required options. Even then, possible security risks are involved. Level 20 should not be used if you are connecting your i5 system to the Internet.

Level 30 probably is the best security level if you are not allowing outside communications with your computer. Not only is the user forced to supply a valid user profile name and password, but the system checks authorities every time the user attempts to perform a task. Level 30 involves more work for the security administrator, because he or she has to define the authorities for all users, but the system is considerably more secure than at level 20. If your company ever experiences a security audit, your i5 system will fail the test if it is at level 20.

Level 30 seems like a tremendous amount of work, but i5/OS includes many tools that simplify the management and maintenance of object authorities. Many techniques also can simplify the task considerably.

Level 40 is the default security level for new machines. It is the preferred security level, especially if you are attaching your system to the Internet. It is almost identical to level 30 except that, under level 40, programs cannot access objects except through "proper channels." When a machine interface (MI) program attempts to access a "system" object (as opposed to a "user" object), the MI program fails. For this reason, IBM claims that security level 40 affords system integrity. This feature is also why level 40 probably can thwart most computer hackers.

Level 50 is even more restrictive than level 40. Under level 40, you can still access some system objects via "supported interfaces," by supplying reserved or invalid parameter values to IBM-supplied programs or APIs. Level 50 blocks this avenue as well.

Changing Security Levels

To go from one security level to another (to either increase or decrease security), you only need to perform two tasks: change system value QSECURITY to the new value and then IPL the system.

For example, suppose your system is running under level 20, and you wish to change it to level 30. Do the following:


When IPL completes, the system will be running under level 30. Note that the level number is enclosed in single quotes.

IBM i5/iSeries Primer(c) Concepts and Techniques for Programmers, Administrators, and Sys[... ]ators
IBM i5/iSeries Primer(c) Concepts and Techniques for Programmers, Administrators, and Sys[... ]ators
Year: 2004
Pages: 245 © 2008-2017.
If you may any questions please contact us: