Determine object ownership

Every object on the system has an owner. The owner has *ALL authority to the object by default.

Object Ownership

Each object is assigned an owner when it is created. The owner is either the user who creates the object or the group profile if the member user profile has specified that the group profile should be the owner of the object. When the object is created, the owner is given all the object and data authorities to the object.

The owner of an object always has all the authority for the object unless any or all authority is removed specifically. As an object owner, you may choose to remove some specific authority as a precautionary measure. For example, if a file exists that contains critical information, you may remove your object existence authority to prevent yourself from accidentally deleting the file. However, as object owner, you can grant any object authority to yourself at any time.

Ownership of an object can be transferred from one user to another. Ownership can be transferred to an individual user profile or a group profile. A group profile can own objects whether or not the group has members.

When changing an object’s owner, you have the option to keep or revoke the former owner’s authority. A user with *ALLOBJ authority can transfer ownership, as can any user who has the following:

Object existence authority for the object, except for an authorization list
Ownership of the object, 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 profile that owns objects. Ownership of objects must be transferred to a new owner or the objects must be deleted before the profile can be deleted. The Delete User Profile (DLTUSRPRF) command allows you to handle owned objects when you delete the profile.

Object ownership is used as a management tool by the system. The owner profile for an object contains a list of all users who have private authority to the object. This information is used to build displays for editing or viewing object authority.

Profiles that own many objects with many private authorities can become very large. The size of a profile that owns many objects affects performance when displaying and working with the authority to objects it owns, and when saving or restoring profiles. System operations can also be impacted. To prevent impacts to either performance or system operations, do not assign objects to only one owner profile for your entire system. Each application and the application objects should be owned by a separate profile. Also, IBM-supplied user profiles should not own user data or objects. The owner of an object also needs sufficient storage for the object.

Default Owner (QDFTOWN) User Profile: The Default Owner (QDFTOWN) user profile is an IBM-supplied user profile that is used when an object has no owner or when object ownership might pose a security exposure. There are several situations that cause ownership of an object to be assigned to the QDFTOWN profile:

If an owning profile becomes damaged and is deleted, its objects no longer have an owner. Using the Reclaim Storage (RCLSTG) command assigns ownership of these objects to the default owner (QDFTOWN) user profile.
If an object is restored and the owner profile does not exist.
If a program that needs to be created again is restored, but the program creation is not successful.
If the maximum storage limit is exceeded for the user profile that owns an authority holder that has the same name as a file being moved, renamed, or whose library is being renamed.

The system supplies the QDFTOWN user profile because all objects must have an owner. When the system is shipped, only a user with *ALLOBJ special authority can display and access this user profile and transfer ownership of objects associated with the QDFTOWN user profile. You can grant other users authority to the QDFTOWN profile. The QDFTOWN user profile is intended for system use only. You should not design your security such that QDFTOWN normally owns object.

Changing application ownership

If your programmer or application provider has created a special profile to own the application libraries and objects, consider using that profile, even if it does not match your naming conventions. Transferring ownership of objects can take a long time and should be avoided. If one of the IBM-supplied group profiles, such as QSECOFR or QPGMR, owns the application, you should transfer ownership to another profile after you install the application. Sometimes programmers design applications to prevent changes in object ownership. Try to work within the restrictions and still meet your own requirements for managing security. However, if an IBM-supplied profile, such as QSECOFR, owns the application, you and your programmer or application provider need to develop a plan to change ownership. Ideally, you should change ownership before you install the application.

Changing public authority

When you save objects, you also save their public authority with them. When you restore an application library to your system, the library and all its objects will have the same public authorities they had when they were saved. This is true even if you saved the library on another system. The CRTAUT value for a library does not affect objects that are restored. They are restored with their saved public authority, regardless of the CRTAUT for the library. You should change the public authority of libraries and objects to match your plan on the Library description form.