Work Management Standards › Implementation of Security › Operational Rights

Operational Rights

The process of specifying authorizations can be extremely time consuming because of all of the many distinctions that can be made. In practice, the default rights that OS/400 gives to new objects give sensible results in most cases. It is usually sufficient to consider changing the default OS/400 operational authorization rights for only two sets of objects:

• Commands and entry-level programs—Granting or revoking operation rights to the entry point to a function (usually a command) prevents unauthorized users from invoking a function.
• Database files—By granting or revoking data operational rights, you can protect data, even if the entry-level protection is circumvented.

The operational rights to all other objects can be left in the public domain (the default).

A significant percentage of IBM i authority problems are caused by users not having the authorization to use certain OS/400 Create commands. The commands commonly required to create temporary work objects are:

• Add Physical File Member (ADDPFM)
• Create Data Area (CRTDTAARA)
• Create Physical File (CRTPF)
• Create Duplicate Object (CRTDUPOBJ)

Note: In the shipped system, the commands do not have public operational authorization. Consider granting public rights to the commands.

On IBM i, you can create an authorization list and attach it to each command. By adding a user profile name to the authorization list, that user profile is immediately authorized to all the commands. Alternatively, the programs that invoke the commands can borrow the rights of the program owner, rather than the user. This is achieved by specifying USRPRF(*OWNER) when creating the program.