Starter Kit- Chapter 4 System iNetwork (formerly iSeries Network)
Home Site Map Contact Us My Profile Log In Join Now!
Info Centers
 Forums

 Tech Center

 News & Analysis

 Solution Center

 UK Centre
Popular Spots
 25th Anniversary

 Article Archive

 ProVIP Center (Club Tech)

 Code

 System i DocFinder

 Essential Guides

 Blogs

 Wikis

 e-Learning

 Webcasts

 Podcasts

 System i Jobs

 Events
Products
 i5 Route Finders

 Learning Center (Store)

 Product Directory
Network Poll
Determining a programmer's desktop requirements is not a black-and-white proposition, but matching equipment to programmer type can help productivity. Which "programmer type" are you?
Vote Now!
Network Memberships
 See Membership Levels

 Free E-Mail Newsletters

 Free RSS Feeds

 Subscribe/Join

 Upgrade Now

 Renew Now
About Us
 About the Network

 Network Publications

 Tech Editor Profiles

 Editorial Calendar

 Contact Us

 Subscribe

 Media Kit (PDF)

 Write For Us


System iNetwork November Sponsor





        System iNetwork November Sponsor


Home » Starter Kit » TOC » Chapter 4
  AS/400-iSeries Starter Kit


Chapter 4 - The Facts About Public Authorities

by Gary Guthrie and Wayne Madden

High among the many strengths of the AS/400 and iSeries 400 is a robust resource security mechanism. Resource security defines users’ authority to objects. There are three categories of authority to an object:

  • Object authority defines the operations that can be performed on an object. Figure 1A describes object authorities.
  • Data authority defines the operations that can be performed on the object’s contents. Figure 1B describes data authorities.
  • Field authority defines the operations that can be performed on data fields. Figure 1C describes field authorities.


Figure 1A – Object authorities

Authority  Description Allowed operations
*ObjOpr Object operational
  • Examine object description
  • Use object as determined by data authorities
  • *ObjMgt  Object management
  • Specify security for object
  • Move or rename object
  • All operations allowed by *ObjAlter and *ObjRef
  • *ObjExist Object existence
  • Delete object
  • Free storage for object
  • Save and restore object
  • Transfer object ownership
  • *ObjAlter Object alter
  • Add, clear, initialize, and reorganize database file members
  • Alter and add database file attributes
  • Add and remove triggers
  • Change SQL package attributes
  • *ObjRefObject reference
  • Specify referential constraint parent
  • *AutLMgt Authorization list management
  • Add and remove users and their authorities from authorization lists

  • Figure 1B – Data authorities

    Authority DescriptionAllowed operations
    *ReadRead
  • Display object’s contents
  • *Add Add
  • Add entries to object
  • *Upd Update
  • Modify object’s entries
  • *Dlt Delete
  • Remove object’s entries
  • *Execute Execute
  • Run a program, service program, or SQL package
  • Locate object in library or directory

  • Figure 1C – Field authorities

    Authority        DescriptionAllowed operations
    *MgtManagement
  • Specify field’s security
  • *AlterAlter
  • Change field’s attributes
  • *RefReference
  • Specify field as part of parent key in referential constraint
  • *ReadRead
  • Access field’s contents
  • *AddAdd
  • Add entries to data
  • *UpdateUpdate
  • Modify field’s existing entries
  • Because of the number of options available, resource security is reasonably complex. It’s important to examine the potential risks — as well as the benefits — of resource security’s default public authority to ensure you maintain a secure production environment.

    What Are Public Authorities?

    Public authority to an object is that default authority given to users who have no specific, or private, authority to the object. That is, the users have no specific authority granted for their user profiles, are not on an authorization list that supplies specific authority, and are not part of a group profile with specific authority.

    When you create an object, either by restoring an object to the system or by using one of the many CrtXxx (Create) commands, public authorities are established. If an object is restored to the system, the public authorities stored with that object are the ones granted to the object. If a CrtXxx command is used to create an object, the Aut (Authority) parameter of that command establishes the public authorities that will be granted to the object.

    Public authority is granted to users in one of several standard authority sets described by the special values *All, *Change, *Use, and *Exclude. Following is a description of each of these values:

    • *All — The user can perform all operations on the object except those limited to the owner or controlled by authorization list management authority. The user can control the object’s existence, grant and revoke authorities for the object, change the object, and use the object. However, unless the user is also the owner of the object, he or she can’t transfer ownership of the object.
    • *Change — The user can perform all operations on the object except those limited to the owner or controlled by object management authority, object existence authority, object alter authority, and object reference authority. The user can perform basic functions on the object; however, he or she cannot change the attributes of the object. Change authority provides object operational authority and all data authority when the object has associated data.
    • *Use — The user can perform basic operations on the object (e.g., open a file, read the records, and execute a program). However, although the user can read and add associated data records or entries, he or she will be prevented from updating or deleting data records or entries. This authority provides object operational authority, read data authority, add data authority, and execute data authority.
    • *Exclude — The user is specifically denied any access to the object.


    Figure 2A shows the individual object authorities defined by the above authority sets. Figure 2B shows the individual data authorities.

    Figure 2A – Individual object authorities

    Authority setObject authorities
     *ObjOpr*ObjMgt*ObjExist *ObjAlter           *ObjRef
    *AllX XXXX
    *ChangeX
    *UseX
    *Exclude 


    Figure 2B – Individual data authorities

    Authority setData authorities
     *Read*Add*Upd *Dlt*Execute
    *AllXXXXX
    *ChangeXXXXX
    *Use XX  X
    *Exclude     

    Creating Public Authority by Default

    When your system arrives, OS/400 offers a means of creating public authorities. This default implementation uses the QCrtAut (Create default public authority) system value, the CrtAut (Create authority) attribute of each library, and the Aut (Public authority) parameter on each of the CrtXxx commands that exist in OS/400.

    System value QCrtAut provides a vehicle for systemwide default public authority. It can have the value *All, *Change, *Use, or *Exclude. *Change is the default for system value QCrtAut when OS/400 is loaded onto your system. QCrtAut alone, though, doesn’t control the public authority of objects created on the system.

    The library attribute CrtAut found on the CrtLib (Create Library) and ChgLib (Change Library) commands defines the default public authority for all objects created in that library. Although the possible values for CrtAut include *All, *Change, *Use, *Exclude, and an authorization list name, the default for CrtAut is *SysVal, which references the value specified in system value QCrtAut. Therefore, when you create a library and don’t specify a value for parameter CrtAut, the system uses the default value *SysVal. The value found in system value QCrtAut is then used to set the default public authority for objects created in the library. You should note, however, that the CrtAut value of the library isn’t used when you create a duplicate object or move or restore an object in the library. Instead, the public authority of the existing object is used.

    The Aut parameter of the CrtXxx commands accepts the values *All, *Change, *Use, *Exclude, and an authorization list name, as well as the special value *LibCrtAut, which is the default value for most of the CrtXxx commands. *LibCrtAut instructs OS/400 to use the default public authority defined by the CrtAut attribute of the library in which the object will exist. In turn, the CrtAut attribute might have a specific value defined at the library level, or it might simply reference system value QCrtAut to get the value.

    Figure 3 shows the effect of the new default values provided for the CrtAut library attribute and the Aut object attribute. The lines and arrows on the right show how each object’s Aut attribute references, by default, the CrtAut attribute of the library in which the object exists. The lines and arrows on the left show how each CrtAut attribute references, by default, the QCrtAut system value.

    The values specified in Figure 3 for the QCrtAut system value, the CrtAut library attribute, and the Aut parameter are the shipped default values. Unless you change those defaults, every object you create on the system with the default value of Aut(*LibCrtAut) will automatically grant *Change authority to the public. (If you use the Replace(*Yes) parameter on the CrtXxx command, the authority of the existing object is used rather than the CrtAut value of the library.)

    If you look closely at Figure 3, you’ll see that although this method may seem to make object authority easier to manage, it’s a little tricky to grasp. First of all, consider that all libraries are defined by a library description that resides in library QSys (even the description of library QSys itself must reside in library QSys). Therefore, the QSys definition of the CrtAut attribute controls the default public authority for every library on the system (not the objects in the libraries, just the library objects themselves) as long as each library uses the default value Aut(*LibCrtAut).

    Executing the command

    DspLibD QSys

    displays the library description of QSys, which reveals that *SysVal is the value for CrtAut. Therefore, if you create a new library using the CrtLib command and specify Aut(*LibCrtAut), users will have the default public authority defined originally in the QCrtAut system value. Remember, at this point the Aut parameter on the CrtLib command is defining only the public authority to the library object.

    As you can see in Figure 3, for each new object created in a library, the Aut(*LibCrtAut) value tells the system to use the default public authority defined by the CrtAut attribute of the library in which the object will exist.

    When implementing default public authorities, consider these facts:

    • You can use the CrtAut library attribute to determine the default public authority for any object created in a given library, provided the object being created specifies *LibCrtAut as the value for the Aut parameter of the CrtXxx command.
    • You can elect to override the *LibCrtAut value on the CrtXxx command and still define the public authority using *All, *Change, *Use, *Exclude, or an authorization list name.
    • The default value for the CrtAut library attribute for new libraries will be *SysVal, instructing the system to use the value found in system value QCrtAut (in effect, controlling new object default public authority at the system level).
    • You can choose to replace the default value *SysVal with a specific default public authority value for that library (i.e., *All, *Change, *Use, *Exclude, or an authorization list name).

    Limiting Public Authority

    The fact that public authority can be created by certain default values brings us to an interesting point. The existence of default values indicates that they are the “suggested” or “normal” values for parameters. In terms of security, you may want to look at default values differently. Default values that define the public authority for objects created on your system are effective only if planned as part of your overall security implementation.

    Your first inclination may be to change QCrtAut to *Use or even *Exclude to reduce the amount of public authority given to new libraries and objects. However, let us warn you that doing so could cause problems with some IBM-supplied functions.

    Another tendency might be to change this system value to *All, hoping that every system object can then be “easily” accessed. Unfortunately, this would be like opening Pandora’s box!

    Here are a few suggestions for effectively planning and implementing object security for your libraries and the objects in those libraries.

    Public Authority by Design

    The most significant threat of OS/400’s default public authority implementation is the possible misuse of the QCrtAut system value. There is no doubt that changing this system value to *All would simplify security, but doing so would simply eliminate security for new libraries and objects — an unacceptable situation for any production machine. Therefore, leave this system value as *Change.

    The first step in effectively implementing public authorities is to examine your user-defined libraries and determine whether the current public authorities are appropriate for the libraries and the objects within those libraries.

    Then, modify the CrtAut attribute of your libraries to reflect the default public authority that should be used for objects created in each library. By doing so, you’re providing the public authority at the library level instead of using the CrtAut(*SysVal) default, which references the QCrtAut system value. As a general rule, use the level of public authority given to the library object (the Aut library attribute) as the default value for the CrtAut library attribute. This is a good starting point for that library.

    Consider this example. Perhaps a library contains only utility program objects that are used by various applications on your system (e.g., date-conversion programs, a binary-to-decimal conversion program, a check object or check authority program). Because all the programs should be available for execution, it’s logical that the CrtAut attribute of this library be set to *Use so that any new objects created in the library will have *Use default public authority.

    Suppose the library you’re working with contains all the payroll and employee data files. You probably want to restrict access to this library and secure it by user profile, group profile, or an authorization list. Any new objects created in this library should probably also have *Exclude public authority unless the program or person creating the object specifically selects a public authority by using the object’s Aut attribute. In this case, you would change the CrtAut attribute to *Exclude.

    The point is this: Public authority at the library level and public authority for objects created in that library must be specifically planned and implemented — not just implemented by default via the QCrtAut system value.

    Object-Level Public Authority

    If you follow the suggestions above concerning the QCrtAut system value and the CrtAut library attribute, Aut(*LibCrtAut) will work well as the default for each object you create. In many cases, the level of public authority at the object level coincides with the public authorities established at the library level. However, it’s important to plan this rather than simply use the default value to save time.

    We hope you now recognize the significance of public authorities and understand the process of establishing them. If you’ve already installed OS/400, examine your user-defined libraries and objects to determine which, if any, changes to public authority are needed.

    This article is excerpted from the book Starter Kit for the IBM iSeries and AS/400 by Gary Guthrie and Wayne Madden, published in April 2001 by 29th Street Press (iSeries Network Store).

    Gary Guthrie is a technical editor for iSeries NEWS. You can reach him by e-mail at gguthrie@iseriesnetwork.com.

    Wayne Madden is editor in chief of iSeries NEWS and the iSeries Network and vice president and group publisher of Penton Technology Media - Loveland's IBM Technology Group.



      Sponsored Links   Featured Links


    Penton Technology Media
    Connected Home | SQL Server Magazine | Windows IT Pro
    Report Bugs | Contact Us | Comments/Suggestions | Terms & Conditions | Privacy Policy | Trademarks
    See Membership Levels | Subscribe | Free E-mail Newsletters | Free RSS Feeds | My Profile | Upgrade Now | Renew Now

    Copyright © 2008 - Penton Technology Media
    Penton Media
    System i is a trademark of International Business Machines Corporation and is used by Penton Media, Inc., under license. SystemiNetwork.com is published independently of International Business Machines Corporation, which is not responsible in any way for the content. Penton Media, Inc., is solely responsible for the editorial content and control of the System iNetwork.