We’ll use the same methodology for discovering who needs access to a database file as we did when securing a directory. First, identify the file(s) you want to secure. Then configure Authority Collection to start collecting information on who’s accessing the file. Finally, start the collection (STRAUTCOL *OBJAUTCOL) if it hasn’t already been started.
IBM did not provide separate commands for enabling Authority Collection on an IFS object versus an object in a library. You must specify all objects using a pathname. This is not difficult once you understand the convention. It’s /QSYS.lib/your-library-name.lib/object-name.object type. See Figure 9.4 for an example.
Figure 9.4: Configure Authority Collection for a database file.
For objects in a library, you can use either the QSYS2.AUTHORITY_COLLECTION_LIBRARIES or QSYS2AUTHORITY_COLLECTION_OBJECT IBM i Service. One performs better than the other, depending on how many entries have been collected for the whole system as well as the specific entries you’re looking for. Personally, I don’t consider this a performance-critical function, so to me you can choose either one, and it really doesn’t matter; the results will be the same. I’ve used the LIBRARIES Service to get the results in Figure 9.5. For an explanation of why I’ve removed the “adopted authority” and “check any authority” fields, see chapter 6.
Figure 9.5: Distinct list of access of the HR_INFO/SALARY file.
Now that you have the list of profiles accessing the file you want to secure, you need to determine how you’re going to secure it.
If the file being secured is associated with an application, you’ll see many, many more entries—those of end users accessing the file via the application. To secure the file, I’d suggest you identify which application programs are accessing the file and change them to adopt authority. In other words, set the User profile attribute of the program to be *OWNER. If the owner of the program is the same as the owner of the file and the program adopts, any caller of the program will have *ALL authority to the file. The easiest way to determine whether any application programs accessed the file would be to turn back to the Authority Collection. The following gets a list of the programs accessing HR_INFO/SALARY that are in the PROD_LIB library.
This is the list of programs you’ll want to consider setting to user profile *OWNER.
Other Access
For access to the file other than through the application, I suggest you attach an authorization list and authorize the profiles accessing the file via non-application interfaces to that list, granting only as much authority as identified in the Authority Collection. While you’ll have to take an outage to attach the list, once attached, you can grant (and revoke) authority to the list at any time. Otherwise, you’ll have to wait until the file isn’t locked to modify the authority to the file. (A database file is locked when it’s opened.) When attaching the list, I’d also set the *PUBLIC authority of the file to *AUTL, meaning that the *PUBLIC authority of the file is to come from the authorization list. That way, when you’re ready to set the *PUBLIC authority to *EXCLUDE, you can do it and not wait for the file to be unlocked. More importantly, if things go terribly wrong for some reason after setting it to *EXCLUDE, you can quickly set it back to the previous value and, again, not have to wait until the file isn’t in use.