|
|
Home » Starter Kit » TOC » Chapter 4
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:
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:
Figure 2A shows the individual object authorities defined by the above authority sets. Figure 2B shows the individual data authorities.
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:
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 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. |