Data Needed to Debug Authority Failures, Part 2
September 28, 2011 Patrick Botz
|
In the first article in this series, I introduced the concept of debugging authority failures and described how the operating system determines whether an executing job should be allowed to access an object. Armed with this information, the topic of this second article, data needed to debug authority failures, will make much more sense. In my third article, I will describe how and where to find this information. Data needed for debugging authority failures can be classified into the following categories: Who, What, When, Which, and Why. Some of this information helps you find other pieces of data. All of it helps you understand why the failure occurred. Don’t worry about where to find this information just yet. We’ll cover that in the next article. WHO Failed? Under which user profiles was the job executing when the authority failure occurred? While many administrators might assume that this must be the user profile representing the person reporting the failing job, often this may not be the case. In the previous article, we described how a job may run under multiple profiles, including the user’s profile, one or more groups of which the user is a member, and one or more adopted user profiles. Further, applications can change the user and group profiles under which a job runs and can “drop adopted authority.” The message is that you have to have some knowledge of how the application works. Does it use adopted authority anywhere? Does it “swap” user profiles or use the qsy_seteuid(), qsy_setegid(), and/or the qsy_setgroups() APIs? You can’t just assume that the user who launched the job is the user profile under which the job is running. WHAT Failed? Which object was the job attempting to access when the authority failure occurred? You need to identify the fully qualified path name and type of object involved in the authority failure. There is no such thing as a “general” authority failure. Jobs don’t receive authority failures unless they are attempting to access an object. This is why giving a profile *ALLOBJ is almost never the best or most appropriate way to solve an authority failure. Sure, it may solve the problem. Then again, a small thermonuclear device will also rid you of gophers in your backyard, but that doesn’t mean it’s the right, most appropriate, or best way to solve the problem. WHEN Did It Fail? You can save a lot of unnecessary time hunting for information if you first verify the approximate date and time of the failure. I’ve attempted to gather information to analyze an authority failure reported in the morning that, after an hour or so of fruitless searching, turned out to have actually occurred at the end of the previous day! Knowing the approximate date and time of the authority failure can significantly reduce the amount of time needed to gather debugging data. WHICH Program or Command Failed? Knowing the fully qualified name of the program that failed can help you determine whether it was an operating system authority failure, some other operating system error, or an “application-defined” authority failure. A real OS authority failure occurs when the user profile(s) under which a job is running does not have enough authority to perform the intended operation on a specified object. Before attempting to debug any authority failure, first ensure that an authority failure actually occurred. I have talked with many customers who insisted they are receiving an authority failure when, in fact, jobs were failing for other reasons. This would not happen if those customers understood the process of debugging authority failures. Jobs can also fail because they lack the proper special authority. Special authority is not another kind of authority–it is really “privilege.” In addition to having authority to an object, some operations also require that you also have privileges (i.e., special authority) to perform the operation. Note that special authority/privilege is associated with an operation, and authority is associated with an object. For example, to change a user profile, you must have *CHANGE authority to the user profile object and also have *SECADM special authority (privilege), which is required to perform many security related operations. Technically, a failure due to a lack of special authority (privilege) is NOT an authority failure. However, the process of debugging special authority failures uses the same general process as authority failures. The biggest difference between the two types of failures is in the way failure is fixed. Application-defined authority failures are generated by applications that implement their own form of security (e.g., menu item access control). These failures are defined by the application itself and therefore require that the application be debugged. WHY Did It Fail? Operating system authority failures occur because the authority of the profiles under which the job was running did not have the proper authority to perform the intended operation on the specified object. Therefore, you need to identify the operation that was attempted on the object involved in the failure (i.e., the “what” information described above). Given the type of operation and the fully qualified object and type information, you can look up the authority users need in order to perform that operation on the object. In this article, we have discussed the Who, What, When, Which, and Why required to debug authority failures. Before making any authority configuration changes, gather this information and analyze it. Doing so will go a very long way toward keeping your data secure. Ultimately, it will also cost you less to manage authority failures over time. Patrick Botz is the principal consultant and founder of Botz & Associates Inc. He is also president of Valid Technologies, LLC, a biometric middleware ISV. Pat spent nearly 20 years working at IBM in various security roles including lead IBM i security architect, IBM eServer security team, and the head of IBM Lab Services Security Consulting practice. Check out his Website at www.botzandassociates.com. Send your questions or comments for Patrick to Ted Holt via the IT Jungle Contact page. RELATED STORY Learn To Debug Authority Failures, Part 1
|
