Plan object authority

Your challenge as security administrator is to protect your organization’s information assets without frustrating the users on your system. You need to make sure that users have enough authority to do their jobs without giving them the authority to browse throughout the system and to make unauthorized changes.

The i5/OS^® operating system provides integrated object security. Users must use the interfaces that the system provides to access objects. For example, if you want to access a database file, use commands or programs that are intended for accessing database files. You cannot use a command that is intended for accessing a message queue or a job log.

Whenever you use a system interface to access an object, the system verifies that you have the authority to the object that is required by that interface. Object authority is a powerful and flexible tool for protecting the assets on your system. Your challenge as a security administrator is to set up an effective object security scheme that you can manage and maintain.

Whenever you try to access an object, the operating system checks your authority to that object. However, if the security level on your system (QSECURITY system value) is set to 10 or 20, every user automatically has authority to access every object because every user profile has *ALLOBJ special authority.

Object authority tip: If you are not sure whether you are using object security, check the QSECURITY (security level) system value. If QSECURITY is 10 or 20, you are not using object security. You must plan and prepare before you change to security level 30 or higher. Otherwise, your users may not be able to access the information that they need.

Following are several suggestions when you restrict authority to IBM-supplied objects:

After you have determined ownership of libraries and objects, you can begin grouping objects on the system. To simplify managing authorities, use an authorization list to group objects with the same requirements. You can then give the public, group profiles, and user profiles authority to the authorization list rather than to the individual objects on the list. The system treats every object that you secure by an authorization list the same, but you can give different users different authorities to the entire list.

An authorization list makes it easier to reestablish authorities when you restore objects. If you secure objects with an authorization list, the restore process automatically links the objects to the list. You can give a group or user the authority to manage an authorization list (*AUTLMGT). Authorization list management allows the user to add and remove other users from the list and to change the authorities for those users.

Authority means the type of access allowed to an object. Different operations require different types of authority.

In some environments, the authority associated with an object is called the object’s mode of access. Authority to an object is divided into three categories:

Description of Authority Types

Authority	Name	Functions allowed
Object Authorities
*OBJOPR	Object Operational	Look at the description of an object. Use the object as determined by the user’s data authorities.
*OBJMGT	Object Management	Specify the security for the object. Move or rename the object. All functions defined for OBJALTER and OBJREF.
*OBJEXIST	Object Existence	Delete the object. Free storage of the object. Perform save and restore operations for the object 1. Transfer ownership of the object.
*OBJALTER	Object Alter	Add, clear, initialize and reorganize members of the database files. Alter and add attributes of database files: add and remove triggers. Change the attributes of SQL packages.
*OBJREF	Object Reference	Specify a database file as the parent in a referential constraint. For example, you want to define a rule that a customer record must exist in the CUSMAS file before an order for the customer can be added to the CUSORD file. You need *OBJREF authority to the CUSMAS file to define this rule.
*AUTLMGT	Authorization List Management	Add and remove users and their authorities from the authorization list 2.
Data Authorities
*READ	Read	Display the contents of the object, such as viewing records in a file.
*ADD	Add	Add entries to an object, such as adding messages to a message queue or adding records to a file.
*UPD	Update	Change the entries in an object, such as changing records in a file.
*DLT	Delete	Remove entries from an object, such as removing messages from a message queue or deleting records from a file.
*EXECUTE	Execute	Run a program, service program, or SQL package. Locate an object in a library or a directory.
Field Authorities
*Mgt	Management	Specify the security for the field.
*Alter	Alter	Change the attributes of the field.
*Ref	Reference	Specify the field as a part of the parent key in a referential constraint
*Read	Read	Access the contents of the field. For example, display the contents of the field.
*Add	Add	Add entries to data, such as adding information to a specific field.
*Update	Update	Change the content of existing entries in the field.
¹ If a user has save system (*SAVSYS) special authority, object existence authority is not required to perform save and restore operations on the object. ² See Authorization List Management for more information.

Commonly used authorities

Certain sets of object and data authorities are commonly required to perform operations on objects. You can specify these system-defined sets of authority (*ALL, *CHANGE, *USE) instead of individually defining the authorities needed for an object. *EXCLUDE authority is different than having no authority. *EXCLUDE authority specifically denies access to the object. Having no authority means you use the public authority defined for the object. The following table shows the system-defined authorities available using the object authority commands and displays.

System-Defined Authority

Authority	*ALL	*CHANGE	*USE
Object Authorities
*OBJOPR	X	X	X
*OBJMGT	X
*OBJEXIST	X
*OBJALTER	X
*OBJREF	X
Data Authorities
*READ	X	X	X
*ADD	X	X
*UPD	X	X
*DLT	X	X
*EXECUTE	X	X	X

The following table shows additional system-defined authorities that are available using the WRKAUT and CHGAUT commands.

System-Defined Authority

Authority	*RWX	*RW	*RX	*R	*WX	*W
Object Authorities
*OBJOPR	X	X	X	X	X	X
*OBJMGT
*OBJEXIST
*OBJALTER
*OBJREF
Data Authorities
*READ	X	X	X	X
*ADD	X	X			X	X
*UPD	X	X			X	X
*DLT	X	X			X	X
*EXECUTE	X		X		X

The LAN Server licensed program uses access control lists to manage authority. A user’s authorities are called permissions. The following table shows how the LAN Server permissions map to object and data authorities.

LAN Server Permissions

Authority	LAN server permissions
*EXCLUDE	None
Object authorities
*OBJOPR	See note 1
*OBJMGT	Permission
*OBJEXIST	Create, Delete
*OBJALTER	Attribute
*OBJREF	No equivalent
Data authorities
*READ	Read
*ADD	Create
*UPD	Write
*DLT	Delete
*EXECUTE	Execute
¹ Unless NONE is specified for a user in the access control list, the user is implicitly given *OBJOPR.

Defining what information can be accessed

You can define resource security for individual objects on the system. You can also define security for groups of objects using either library security or an authorization list:

Library Security:
Most objects on the system reside in libraries. To access an object, you need authority both to the object itself and the library in which the object resides. For most operations, including deleting an object, *USE authority to the object library is sufficient (in addition to the authority required for the object). Creating a new object requires *ADD authority to the object library. Appendix D shows what authority is required by CL commands for objects and the object libraries.
Using library security is one technique for protecting information while maintaining a simple security scheme. For example, to secure confidential information for a set of applications, you could do the following:
- Use a library to store all confidential files for a particular group of applications.
- Ensure that public authority is sufficient for all objects (in the library) that are used by applications (*USE or *CHANGE).
- Restrict public authority to the library itself (*EXCLUDE).
- Give selected groups or individuals authority to the library (*USE, or *ADD if the applications require it).
Although library security is a simple, effective method for protecting information, it may not be adequate for data with high security requirements. Highly sensitive objects should be secured individually or with an authorization list, rather than relying on library security.
Library Security and Library Lists:
When a library is added to a user’s library list, the authority the user has to the library is stored with the library list information. The user’s authority to the library remains for the entire job, even if the user’s authority to the library is revoked while the job is active.
When access is requested to an object and *LIBL is specified for the object, the library list information is used to check authority for the library. If a qualified name is specified, the authority for the library is specifically checked, even if the library is included in the user’s library list.
If a user is running under adopted authority when a library is added to the library list, the user remains authorized to the library even when the user is no longer running under adopted authority. This represents a potential security exposure. Any entries added to a user’s library list by a program running under adopted authority should be removed before the adopted authority program ends. In addition, applications that use library lists rather than qualified library names have a potential security exposure. A user who is authorized to the commands to work with library lists could potentially run a different version of a program. See Library Lists for more information.
Field Authorities:
Field authorities are now supported for database files. Authorities supported are Reference and Update. You can only administer these authorities through the SQL statements, GRANT and REVOKE. You can display these authorities through the Display Object Authority (DSPOBJAUT) and the Edit Object Authority (EDTOBJAUT) commands. You can only display the field authorities with the EDTOBJAUT command; you cannot edit them.
Changes for field authorities include the following:
- The Print Private Authority (PRTPVTAUT) command has a new field that indicates when a file has field authorities.
- The Display Object Authority (DSPOBJAUT) command now has a new Authority Type parameter to allow display of object authorities, field authorities, or all authorities. If the object type is not *FILE, you can display only object authorities.
- Information provided by List Users Authorized to Object (QSYLUSRA) API now indicates if a file has field authorities.
- The Grant User Authority (GRTUSRAUT) command will not grant a user’s field authorities.
- When a grant with reference object is performed using the GRTOBJAUT command and both objects (the one being granted to and the referenced one) are database files, all field authorities will be granted where the field names match.
- If a user’s authority to a database file is removed, any field authorities for the user are also removed.
Security and the System/38™ Environment:
The System/38 Environment and CL programs of type CLP38 represent a potential security exposure. When a non-library qualified command is entered from the System/38 Command Entry screen, or invoked by any CLP38 CL program, library QUSER38 (if it exists) is the first library searched for that command. Library QSYS38 is the second library searched. A programmer or other knowledgeable user could place another CL command in either of these libraries and cause that command to be used instead of one from a library in the library list.
Library QUSER38 is not shipped with the operating system. However, it can be created by anyone with enough authority to create a library. See the System/38 Environment Programming manual for more information about the System/38 Environment.
Recommendation for System/38 Environment: Use these measures to protect your system for the System/38 Environment and CL programs of type CLP38:
- Check the public authority of the QSYS38 library and if it is *ALL or *CHANGE then change it to *USE.
- Check the public authority of the QUSER38 library and if it is *ALL or *CHANGE then change it to *USE.
- If the QUSER38 and QSYS38 do not exist then create them and set them to public *USE authority. This will prevent anyone else from creating it at a later time and giving themselves or the public too much authority to it.
Directory Security:
When accessing an object in a directory, have authority to all the directories in the path containing the object. You must also have the necessary authority to the object to perform the operation you requested.
You may want to use directory security in the same way that you use library security. Limit access to directories and use public authority to the objects within the directory. Limiting the number of private authorities defined for objects improves the performance of the authority checking process.
Authorization List Security:
You can group objects with similar security requirements using an authorization list. An authorization list, conceptually, contains a list of users and the authority that the users have to the objects secured by the list. Each user can have a different authority to the set of objects the list secures. When you give a user authority to the authorization list, the operating system actually grants a private authority for that user to the authorization list.
You can also use an authorization list to define public authority for the objects on the list. If the public authority for an object is set to *AUTL, the object gets its public authority from its authorization list.
The authorization list object is used as a management tool by the system. It actually contains a list of all objects which are secured by the authorization list. This information is used to build displays for viewing or editing the authorization list objects.
You cannot use an authorization list to secure a user profile or another authorization list. Only one authorization list can be specified for an object.
Only the owner of the object, a user with all object (*ALLOBJ) special authority, or a user with all (*ALL) authority to the object, can add or remove the authorization list for an object. Objects in the system library (QSYS) can be secured with an authorization list. However, the name of the authorization list that secures an object is stored with the object.
In some cases, when you install a new release of the operating system, all the objects in the QSYS library are replaced. The association between the objects and your authorization list would be lost. See the topic Planning Authorization Lists for examples of how to use authorization lists.
Authorization List Management: You can grant a special operational authority called Authorization List Management (*AUTLMGT) for authorization lists. Users with *AUTLMGT authority are allowed to add and remove the users’ authority to the authorization list and change the authorities for those users. *AUTLMGT authority, by itself, does not give authority to secure new objects with the list or to remove objects from the list.
A user with *AUTLMGT authority can give only the same or less authority to others. For example, assume USERA has *CHANGE and *AUTLMGT authority to authorization list CPLIST1. USERA can add USERB to CPLIST1 and give USERB *CHANGE authority or less. USERA cannot give USERB *ALL authority to CPLIST1, because USERA does not have *ALL authority.
A user with *AUTLMGT authority can remove the authority for a user if the *AUTLMGT user has equal or greater authority to the list than the user profile name being removed. If USERC has *ALL authority to CPLIST1, then USERA cannot remove USERC from the list, because USERA has only *CHANGE and *AUTLMGT.
Using Authorization Lists to Secure IBM-Supplied Objects: You may choose to use an authorization list to secure IBM-supplied objects. For example, you may want to restrict the use of a group of commands to a few users. Objects in IBM-supplied libraries, other than the QUSRSYS and QGPL libraries, are replaced whenever you install a new release of the operating system. Therefore, the link between objects in IBM-supplied libraries and authorization lists is lost. Also, if an authorization list secures an object in QSYS and a complete system restore is required, the link between the objects in QSYS and the authorization list is lost. After you install a new release or restore your system, use the EDTOBJAUT or GRTOBJAUT command to re-establish the link between the IBM-supplied object and the authorization list.
The Implementation Guide for AS/400^® Security and Auditing redbook contains sample programs, such as ALLAUTL and FIXAUTL, that can be used to attach authorization lists to the objects after the authorization lists are restored.

Authority for new objects in a library

Every library has a parameter called CRTAUT (create authority). This parameter determines the default public authority for any new object that is created in that library. When you create an object, the AUT parameter on the create command determines the public authority for the object. If the AUT value on the create command is *LIBCRTAUT, which is the default, the public authority for the object is set to the CRTAUT value for the library.

For example, assume library CUSTLIB has a CRTAUT value of *USE. Both of the commands below create a data area called DTA1 with public authority *USE:

Specifying the AUT parameter: CRTDTAARA DTAARA(CUSTLIB/DTA1) + TYPE(*CHAR) AUT(*LIBCRTAUT)
Allowing the AUT parameter to default. *LIBCRTAUT is the default: CRTDTAARA DTAARA(CUSTLIB/DTA1) + TYPE(*CHAR)

The default CRTAUT value for a library is *SYSVAL. Any new objects created in the library using AUT(*LIBCRTAUT) have public authority set to the value of the QCRTAUT system value. The QCRTAUT system value is shipped as *CHANGE. For example, assume the ITEMLIB library has a CRTAUT value of *SYSVAL. This command creates the DTA2 data area with public authority of change: CRTDTAARA DTAARA(ITEMLIB/DTA2) + TYPE(*CHAR) AUT(*LIBCRTAUT)

Several IBM-supplied libraries, including QSYS, have a CRTAUT value of *SYSVAL. If you change QCRTAUT to something other than *CHANGE, you may encounter problems. For example, devices are created in the QSYS library. The default when creating devices is AUT(*LIBCRTAUT).

The CRTAUT value for the QSYS library is *SYSVAL. If QCRTAUT is set to *USE or *EXCLUDE, public authority is not sufficient to allow sign-on at new devices.

The CRTAUT value for a library can also be set to an authorization list name. Any new object created in the library with AUT(*LIBCRTAUT) is secured by the authorization list. The public authority for the object is set to *AUTL.

The CRTAUT value of the library is not used during a move (MOVOBJ), create duplicate (CRTDUPOBJ), or restore of an object into the library. The public authority of the existing object is used.

If the REPLACE (*YES) parameter is used on the create command, then the authority of the existing object is used instead of the CRTAUT value of the library. Create Authority (CRTAUT) Risks: If your applications use default authority for new objects created during application processing, you should control who has authority to change the library descriptions. Changing the CRTAUT authority for an application library could allow unauthorized access to new objects created in the library.

Authority for new objects in a directory

When you create a new object in a directory using the CRTDIR, MD or MKDIR commands, you specify the data authority and object authority that the public receives for the object. If you use the *INDIR option, the authority for the created directory is determined from the directory it is being created in. Otherwise, you can specify the specific desired authority.

Objects that adopt the owner's authority

Sometimes a user needs different authorities to an object or an application, depending on the situation. For example, a user may be allowed to change the information in a customer file when using application programs providing that function. However, the same user should be allowed to view, but not change, customer information when using a decision support tool, such as SQL.

A solution to this situation is 1) give the user *USE authority to customer information to allow querying the files and 2) use adopted authority in the customer maintenance programs to allow the user to change the files.

When an object uses the owner’s authority, this is called adopted authority. Objects of type *PGM, *SRVPGM, *SQLPKG and Java™ programs can adopt authority. When you create a program, you specify a user profile (USRPRF) parameter on the CRTxxxPGM command. This parameter determines whether the program uses the authority of the owner of the program in addition to the authority of the user running the program.

The following applies to adopted authority:

Adopted authority is added to any other authority found for the user.
Adopted authority is checked only if the authority that the user, the user’s group, or the public has to an object is not adequate for the requested operation.
The special authorities (such as *ALLOBJ) in the owner’s profile are used.
If the owner profile is a member of a group profile, the group’s authority is not used for adopted authority.
Public authority is not used for adopted authority. For example, USER1 runs the program LSTCUST, which requires *USE authority to the CUSTMST file:
- Public authority to the CUSTMST file is *USE.
- USER1’s authority is *EXCLUDE.
- USER2 owns the LSTCUST program, which adopts owner authority.
- USER2 does not own the CUSTMST file and has no private authority to it.
- Although public authority is sufficient to give USER2 access to the CUSTMST file, USER1 does not get access. Owner authority, primary group authority, and private authority are used for adopted authority.
- Only the authority is adopted. No other user profile attributes are adopted. For example, the limited capabilities attributes are not adopted.
Adopted authority is active as long as the program using adopted authority remains in the program stack. For example, assume PGMA uses adopted authority:
- If PGMA starts PGMB using the CALL command, these are the program stacks before and after the CALL command:
  
  Adopted Authority and the CALL Command
  Program stack before CALL command Program stack after CALL command
  
  QCMD
  .
  .
  .
  PGMA
  
  QCMD
  .
  .
  .
  PGMA
  PGMB
  
  Because PGMA remains in the program stack after PGMB is called, PGMB uses the adopted authority of PGMA. (The use adopted authority (USEADPAUT) parameter can override this.
- If PGMA starts PGMB using the Transfer Control (TFRCTL) command, the program stacks look like this:
  
  Adopted Authority and the TFRCTL Command
  Program stack before TFRCTL command Program stack after TFRCTL command
  
  QCMD
  .
  .
  .
  PGMA
  
  QCMD
  .
  .
  .
  PGMB
  
  PGMB does not use the adopted authority of PGMA, because PGMA is no longer in the program stack.
If the program running under adopted authority is interrupted, the use of adopted authority is suspended. The following functions do not use adopted authority:
- System request
- Attention key (If a Transfer to Group Job (TFRGRPJOB) command is running, adopted authority is not passed to the group job)
- Break-message-handling program
- Debug functions
Adopted authority is immediately interrupted by the attention key or a group job request. The user must have authority to the attention-key-handling program or the group job initial program, or the attempt fails.

Program stack before CALL command	Program stack after CALL command
QCMD . . . PGMA	QCMD . . . PGMA PGMB

Program stack before TFRCTL command	Program stack after TFRCTL command
QCMD . . . PGMA	QCMD . . . PGMB

For example, USERA runs the program PGM1, which adopts the authority of USERB. PGM1 uses the SETATNPGM command and specifies PGM2. USERB has *USE authority to PGM2. USERA has *EXCLUDE authority to PGM2. The SETATNPGM function is successful because it is run using adopted authority. USERA receives an authority error when attempting to use the attention key because USERB’s authority is no longer active.

If a program that uses adopted authority submits a job, that submitted job does not have the adopted authority of the submitting program.
When a trigger program or exit point program is called, adopted authority from previous programs in the call stack will not be used as a source of authority for the trigger program or exit point program.
The program adopt function is not used when you use the Change Job (CHGJOB) command to change the output queue for a job. The user profile making the change must have authority to the new output queue.
Any objects created, including spooled files, are owned by the user of the program or by the user’s group profile, not by the owner of the program.
Adopted authority can be specified on either the command that creates the program (CRTxxxPGM) or on the Change Program (CHGPGM) command.
If a program is created using REPLACE(*YES) on the CRTxxxPGM command, the new copy of the program has the same USRPRF, USEADPAUT, and AUT values as the replaced program. The USRPRF and AUT parameters specified on the CRTxxxPGM parameter are ignored.
Only the owner of the program can specify REPLACE(*YES) on the CRTxxxPGM command when USRPRF(*OWNER) is specified on the original program.
Only a user who owns the program or has *ALLOBJ and *SECADM special authorities can change the value of the USRPRF parameter.
You must be signed on as a user with *ALLOBJ and *SECADM special authorities to transfer ownership of an object that adopts authority.
If someone other than the program’s owner or a user with *ALLOBJ and *SECADM special authorities restores a program that adopts authority, all private and public authorities to the program are revoked to prevent a possible security exposure.

The Display Program (DSPPGM) and Display Service Program (DSPSRVPGM) commands show whether a program adopts authority (User profile prompt) and whether it uses adopted authority from previous programs in the program stack (Use adopted authority prompt). The Display Program Adopt (DSPPGMADP) command shows all the objects that adopt the authority of a specific user profile. The Print Adopting Objects (PRTADPOBJ) command provides a report with more information about objects that adopt authority. This command also provides an option to print a report for objects that changed since the last time the command was run.

Adopted Authority and Bound Programs: An ILE* program (*PGM) is an object that contains one or more modules. It is created by an ILE* compiler. An ILE program can be bound to one or more service programs (*SRVPGM).

To activate an ILE program successfully, the user must have *EXECUTE authority to the ILE program and to all service programs to which it is bound. If an ILE program uses adopted authority from a program higher in the program call stack, that adopted authority is used to check authority to all service programs to which the ILE program is bound. If the ILE program adopts authority, the adopted authority will not be checked when the system checks the user’s authority to the service programs at program activation time.

Adopted Authority Risks and Recommendations: Allowing a program to run using adopted authority is an intentional release of control. You permit the user to have authority to objects, and possibly special authority, which the user would not normally have. Adopted authority provides an important tool for meeting diverse authority requirements, but it should be used with care:

Adopt the minimum authority required to meet the application requirements. Adopting the authority of an application owner is preferable to adopting the authority of QSECOFR or a user with *ALLOBJ special authority.
Carefully monitor the function provided by programs that adopt authority. Make sure these programs do not provide a means for the user to access objects outside the control of the program, such as command entry capability.
Programs that adopt authority and call other programs must perform a library qualified call. Do not use the library list (*LIBL) on the call.
Control which users are permitted to call programs that adopt authority. Use menu interfaces and library security to prevent these programs from being called without sufficient control.

Programs that ignore adopted authority

You may not want some programs to use the adopted authority of previous programs in the program stack. For example, if you use an initial menu program that adopts owner authority, you may not want some of the programs called from the menu program to use that authority.

The use adopted authority (USEADPAUT) parameter of a program determines whether the system uses the adopted authority of previous programs in the stack when checking authority for objects. When you create a program, the default is to use adopted authority from previous programs in the stack. If you do not want the program to use adopted authority, you can change the program with the Change Program (CHGPGM) command or Change Service Program (CHGSRVPGM) command to set the USEADPAUT parameter to *NO. If a program is created using REPLACE(*YES) on the CRTxxxPGM command, the new copy of the program has the same USRPRF, USEADPAUT, and AUT values as the replaced program.

In some situations, you can use the MODINVAU MI instruction to prevent passing adopted authority to called functions. The MODINVAU instruction can be used to prevent passing any adopted authority from C and C++ programs to called functions in another program or service program. This may be useful when you do not know the USEADPAUT setting of the function that is called.

Authority holders

An authority holder is a tool for keeping the authorities for a program-described database file that does not currently exist on the system. Its primary use is for System/36 environment applications, which often delete program-described files and create them again. An authority holder can be created for a file that already exists or for a file that does not exist, using the Create Authority Holder (CRTAUTHLR) command. The following applies to authority holders:

Authority holders can only secure files in the system auxiliary storage pool (ASP) or a basic user ASP. They cannot secure files in an independent ASP.
The authority holder is associated with a specific file and library. It has the same name as the file.
Authority holders can be used only for program-described database files and logical files created in the S/36 environment.
Once the authority holder is created, you add private authorities for it like a file. Use the commands to grant, revoke, and display object authorities, and specify object type *FILE. On the object authority displays, the authority holder is indistinguishable from the file itself. The displays do not indicate whether the file exists nor do they show that the file has an authority holder.
If a file is associated with an authority holder, the authorities defined for the authority holder are used during authority checking. Any private authorities defined for the file are ignored.
Use the Display Authority Holder (DSPAUTHLR) command to display or print all the authority holders on the system. You can also use it to create an output file (Outfile) for processing.
If you create an authority holder for a file that exists:
- The user creating the authority holder must have *ALL authority to the file.
- The owner of the file becomes the owner of the authority holder regardless of the user creating the authority holder.
- The public authority for the authority holder comes from the file. The public authority (AUT) parameter on the CRTAUTHLR command is ignored.
- The existing file’s authority is copied to the authority holder.
If you create a file and an authority holder for that file already exists:
- The user creating the file must have *ALL authority to the authority holder.
- The owner of the authority holder becomes the owner of the file regardless of the user creating the file.
- The public authority for the file comes from the authority holder. The public authority (AUT) parameter on the CRTPF or CRTLF command is ignored.
- The authority holder is linked to the file. The authority specified for the authority holder is used to secure the file.
If an authority holder is deleted, the authority information is transferred to the file itself.
If a file is renamed and the new file name matches an existing authority holder, the authority and ownership of the file are changed to match the authority holder. The user renaming the file needs *ALL authority to the authority holder.
If a file is moved to a different library and an authority holder exists for that file name and the target library, the authority and ownership of the file are changed to match the authority holder. The user moving the file must have *ALL authority to the authority holder.
Ownership of the authority holder and the file always match. If you change the ownership of the file, ownership of the authority holder also changes.
When a file is restored, if an authority holder exists for that file name and the library to which it is being restored, it is linked to the authority holder.
Authority holders cannot be created for files in these libraries: QSYS, QRCL, QRECOVERY, QSPL, QTEMP, and QSPL0002 – QSPL0032.

Authority Holders and System/36 Migration: The System/36 Migration Aid creates an authority holder for every file that is migrated. It also creates an authority holder for entries in the System/36 resource security file if no corresponding file exists on the System/36. You need authority holders only for files that are deleted and re-created by your applications. Use the Delete Authority Holder (DLTAUTHLR) command to delete any authority holders that you do not need.

Authority Holder Risks: An authority holder provides the capability of defining authority for a file before that file exists. Under certain circumstances, this could allow an unauthorized user to gain access to information. If a user knew that an application would create, move, or rename a file, the user could create an authority holder for the new file. The user would thus gain access to the file. To limit this exposure, the CRTAUTHLR command is shipped with public authority *EXCLUDE. Only users with *ALLOBJ authority can use the command, unless you grant authority to others.

Working with authority

This information describes commonly-used methods for setting up, maintaining, and displaying authority information on your system. "Security commands" provides a complete list of the commands available for working with authority. The descriptions that follow do not discuss all the parameters for commands or all the fields on the displays.

Authority displays

Four displays show object authorities:

Display Object Authority display
Edit Object Authority display
Display Authority display
Work with Authority display

If you have *OBJMGT authority to an object, you see all private authorities for that object. If you do not have *OBJMGT authority, you see only your own sources of authority for the object.
The *ADOPTED authority indicates only the additional authority received from the program owner.

Authority reports

Several reports are available to help you monitor your security implementation. For example, you can monitor objects with *PUBLIC authority other than *EXCLUDE and objects with private authorities with the following commands:

Print Public Authority (PRTPUBAUT)
Print Private Authority (PRTPVTAUT)

Working with libraries

Two parameters on the Create Library (CRTLIB) command affect authority:

Authority (AUT): The AUT parameter can be used to specify either of the following:
- The public authority for the library
- The authorization list that secures the library.
The AUT parameter applies to the library itself, not to the objects in the library. If you specify an authorization list name, the public authority for the library is set to *AUTL. If you do not specify AUT when you create a library, *LIBCRTAUT is the default. The system uses the CRTAUT value from the QSYS library, which is shipped as *SYSVAL.
Create Authority (CRTAUT): The CRTAUT parameter determines the default authority for any new objects that are created in the library. CRTAUT can be set to one of the system-defined authorities (*ALL, *CHANGE, *USE, or *EXCLUDE), to *SYSVAL (the QCRTAUT system value), or to the name of an authorization list.

You can change the CRTAUT value for a library using the Change Library (CHGLIB) command.

Creating objects

When you create a new object, you can either specify the authority (AUT) or use the default, *LIBCRTAUT.

Working with individual object authority

To change the authority for an object have one of the following:

*ALLOBJ authority or membership in a group profile that has *ALLOBJ special authority.

The group’s authority is not used if you have private authority to the object.
Ownership of the object. If a group profile owns the object, any member of the group can act as the object owner, unless the member has been given specific authority that does not meet the requirements for changing the object’s authority.
*OBJMGT authority to the object and any authorities being granted or revoked (except *EXCLUDE). Any user who is allowed to work with the object’s authority can grant or revoke *EXCLUDE authority.

The easiest way to change authority for an individual object is with the Edit Object Authority display. This display can be called directly by using the Edit Object Authority (EDTOBJAUT) command or selected as an option from the Work with Objects by Owner (WRKOBJOWN) or WRKOBJ (Work with Objects) display. You can also use these commands to change object authority:

Change Authority (CHGAUT)
Work with Authority (WRKAUT)
Grant Object Authority (GRTOBJAUT)
Revoke Object Authority (RVKOBJAUT)

To specify the generic authority subsets, such as Read/Write (*RX) or Write/Execute (*WX), use the CHGAUT or WRKAUT commands.

Specifying user-defined authority

The Object Authority column on the Edit Object Authority display allows you to specify any of the system-defined sets of authorities (*ALL, *CHANGE, *USE, *EXCLUDE). If you want to specify authority that is not a system-defined set, use F11 (Display detail).

If the User options (USROPT) field in your user profile is set to *EXPERT, you always see this detailed version of the display without having to press F11. You can press F11 (Display data authorities) to view or change the data authorities. To give authority to additional users, press F6 (Add new users) from the Edit Object Authority display. You see the Add New Users display, which allows you to define authority for multiple users.

Removing a user’s authority for an object is different from giving the user *EXCLUDE authority. *EXCLUDE authority means the user is specifically not allowed to use the object. Only *ALLOBJ special authority and adopted authority override *EXCLUDE authority. Removing a user’s authority means the user has no specific authority to the object. The user can gain access through a group profile, an authorization list, public authority, *ALLOBJ special authority, or adopted authority.

You can remove a user’s authority using the Edit Object Authority display. Type blanks in the Object Authority field for the user and press the Enter key. The user is removed from the display. You can also use the Revoke Object Authority (RVKOBJAUT) command. Either revoke the specific authority the user has or revoke *ALL authority for the user.

The RVKOBJAUT command revokes only the authority you specify. For example, USERB has *ALL authority to FILEB in library LIBB. You revoke *CHANGE authority: RVKOBJAUT OBJ(LIBB/FILEB) OBJTYPE(*FILE) + USER(*USERB) AUT(*CHANGE)

Working with authority for multiple objects

The Edit Object Authority display allows you to interactively work with the authority for one object at a time. The Grant Object Authority (GRTOBJAUT) command allows you to make authority changes to more than one object at a time. You can use the GRTOBJAUT authority command interactively or in batch. You can also call it from a program. Following are examples of using the GRTOBJAUT command, showing the prompt display. When the command runs, you receive a message for each object indicating whether the change was made. Authority changes require an exclusive lock on the object and cannot be made when an object is in use. Print your job log for a record of changes attempted and made. To give all the objects in the TESTLIB library a public authority of *USE:

Grant Object Authority (GRTOBJAUT)

Type choices, press Enter. 
Object . . . . . . . . . . . . . *ALL 
Library . . . . . . . . . . . . . TESTLIB 
Object type . . . . . . . . . . *ALL ASP device . . . . . . . . . . . * 
Users . . . . . . . . . . . . . *PUBLIC 
+ for more values 
Authority . . . . . . . . . . . *USE

This example for the GRTOBJAUT command gives the authority you specify, but it does not remove any authority that is greater than you specified. If some objects in the TESTLIB library have public authority *CHANGE, the command just shown would not reduce their public authority to *USE. To make sure that all objects in TESTLIB have a public authority of *USE, use the GRTOBJAUT command with the REPLACE parameter: GRTOBJAUT OBJ(TESTLIB/*ALL) OBJTYPE(*ALL) + USER(*PUBLIC) REPLACE(*YES)

The REPLACE parameter indicates whether the authorities you specify replaces the existing authority for the user. The default value of REPLACE(*NO) gives the authority that you specify, but it does not remove any authority that is greater than the authority you specify, unless you are granting *EXCLUDE authority. These commands set public authority only for objects that currently exist in the library. To set the public authority for any new objects that are created later, use the CRTAUT parameter on the library description.

Working with object ownership

To change ownership of an object, use one of the following:

The Change Object Owner (CHGOBJOWN) command
The Work with Objects by Owner (WRKOBJOWN) command
The Change Owner (CHGOWN) command

The Work with Objects by Owner display shows all the objects owned by a profile. You can assign individual objects to a new owner. You can also change ownership for more than one object at a time by using the NEWOWN (new owner) parameter at the bottom of the display. When you change ownership using either method, you can choose to remove the previous owner’s authority to the object. The default for the CUROWNAUT (current owner authority) parameter is *REVOKE. To transfer ownership of an object, have:

Object existence authority for the object
*ALL authority or ownership, if the object is an authorization list
Add authority for the new owner’s user profile
Delete authority for the present owner’s user profile

You cannot delete a user profile that owns objects. The Work with Objects by Owner display includes integrated file system objects. For these objects, the Object column on the display shows the first 18 characters of the path name. If the path name is longer than 18 characters, a greater than symbol (>) appears at the end of the path name. To see the absolute path name, place your cursor anywhere on the path name and press the F22 key.

Resource security

Resource security on the system allows you to define who can use objects and how those objects can be used. The ability to access an object is called authority. When you set up object authority, you can need to be careful to give your users enough authority to do their work without giving them the authority to browse and change the system.

Object authority gives permissions to the user for a specific object and can specify what the user is allowed to do with the object. An object resource can be limited through specific detailed user authorities, such as adding records or changing records. System resources can be used to give the user access to specific system-defined subsets of authorities: *ALL, *CHANGE, *USE, and *EXCLUDE. Files, programs, libraries, and directories are the most common system objects that require resource security protection, but you can specify authority for any individual object on the system.

Understanding the types of authority: After you have determined your objectives for your resource security and recorded your decisions on the Library Description form, you can begin to plan types of authority. Resource security defines how users have access to objects on the system.

Authority means how someone is authorized to use an object. For example, you may have the authority to view information or to change information on the system. The system provides several different authority types. IBM groups these authority types into categories, called system-defined authorities, which meet the needs of most people. The table below lists the categories and tells how they apply to securing files and programs.

Refer to the tables below when you plan authorities.

System-defined authorities

Authority name	Operations allowed for files	Operations not allowed for files	Operations allowed for programs	Operations not allowed for programs
*USE	View information in the file.	Change or delete any information in the file. Delete the file.	Run the program.	Change or delete the program
*CHANGE	View, change and delete records in the file.	Delete or clear the entire file.	Change the description of the program.	Change or delete the program.
*ALL	Create and delete the file. Add, change and delete records in the file. Authorize others to use the file.	None	Create, change and delete the program. Authorize others to use the program.	Change the owner of the program, if the program adopts authority.
*EXCLUDE¹	None	Any access to the file.	None	Any access to the program.
¹ *EXCLUDE overrides any authorities that you grant to the public or through a group profile.

To design simple resource security, try to plan security for entire libraries. To do this, you need to understand how the system-defined authorities apply to libraries, which the table below shows:

System-defined authorities for libraries

Authority name	Operations allowed	Operations not allowed
*USE	For objects in the library, any operation allowed by the authority to the specific object. For the library, view descriptive information.	Add new objects to the library. Change the library description. Delete the library.
*CHANGE	For objects in the library, any operation allowed by the authority to the specific object. Add new objects to the library. Change the library description.	Delete the library.
*ALL	Everything allowed with change. Delete the library. Authorize others to the library.	None.

Authority name

Operations allowed

Operations not allowed

*USE

For objects in the library, any operation allowed by the authority to the specific object.
For the library, view descriptive information.

Add new objects to the library.
Change the library description.
Delete the library.

*CHANGE

For objects in the library, any operation allowed by the authority to the specific object.
Add new objects to the library.
Change the library description.

Delete the library.

*ALL

Everything allowed with change.
Delete the library.
Authorize others to the library.

None.

You also need to understand how library and object authority work together. The table below gives examples of authorities that are required for both an object and the library:

How library authority and object authority work together

Object type	Operations	Object authority needed	Library authority needed
File	Change data	*CHANGE	*USE
File	Delete the file	*ALL	*USE
File	Create the file	*ALL	*CHANGE
Program	Run the program	*USE	*USE
Program	Change (recompile) the program	*ALL	*CHANGE
Program	Delete the program	*ALL	*USE

Directory authority is similar to library authority. You need authority to all the directories in the path name for an object in order to access the object.

Parent topic:

Planning application security

Planning object authority

Parent topic: