Authority collection is an incredible tool for performing “security reconnaissance”. This is one of the primary use cases for authority collection. Authority collection (hereafter referred to as AC) can be applied at the user profile level to capture details about the security checks that happen for a specific user profile on all of the objects that they access. Alternatively, AC can be applied at the object level (including QSYS objects as well as IFS files/directories) to capture details about every security check that happens for a specific object, path, or stream file. The collected AC data can only be viewed using SQL views.
Authorities (or privileges) in the IFS are related to the authorities that we find in the traditional QSYS library/object arena, but the IFS also has its own unique quirks. Libraries and objects have “object authorities” and “data authorities”. The common authority definitions like *ALL, *CHANGE, and *USE can be mapped to the specific object and data authority configurations below:
| Object Authorities | Data Authorities | |||||||||
| ObjOpr | ObjMgt | ObjExist | ObjAlter | ObjRef | Read | Add | Update | Delete | Execute | |
| *ALL | X | X | X | X | X | X | X | X | X | X |
| *CHANGE | X | X | X | X | X | X | ||||
| *USE | X | X | X | |||||||
| *EXCLUDE | ||||||||||
Objects in the IFS also have “object authorities” and “data authorities”. However, the common *RWX (read, write, execute) authorities map only to the data authorities. The “object authorities” are independent of the *R, *W, and *X settings.
| Object Authorities | Data Authorities | |||||||||
| Exist | Mgt | Alter | Ref | ObjOpr | Read | Add | Update | Delete | Execute | |
| *R | X | X | ||||||||
| *W | X | X | X | X | ||||||
| *X | X | |||||||||
| *RW | X | X | X | X | X | |||||
| *RX | X | X | X | |||||||
| *WX | X | X | X | X | X | |||||
| *RWX | X | X | X | X | X | X | ||||
Prior to i 7.6 the IBM-supplied view for reviewing your AC data was called qsys2.authority_collection_fsobj. When using this view, any authority-related details such as “detailed current authority” and “detailed required authority” are displayed in the QSYS authority style. For example, below is a view of the current authority on a file in the IFS viewed from both the DSPAUT command as well as the qsys2.authority_collection_fsobj SQL view:


Note that the *RWX setting (visible in the first screenshot) corresponds with a specific set of data authorities as detailed in the second table above. However, the “*RWX” authority setting is not shown in the data returned by the SQL view (second screenshot). This complicates efforts to use the AC data to set authorities on your IFS objects.
In OS version 7.6 IBM introduced a new SQL view for accessing IFS AC data. The view is called qsys2.authority_collection_ifs and it serves two purposes:
1. Standardization – The authorities are displayed in a format that matches what you would see in the WRKLNK and WRKAUT screens. This makes it easier to reach conclusions about authority requirements and apply them in your security remediation efforts.
2. Simplification – Remember the adage “sometimes less is more”. This new view returns fewer columns than the old view, omitting unnecessary or potentially-misleading details. This provides a more intuitive and insightful view of the data.
In terms of standardization, when using this new view to display the AC data, the authorities are displayed in a way that is consistent with the concept of “read, write, execute” or *R *W and *X as shown here:

In terms of simplification, the number of columns returned by the old view (63) is greatly reduced in the new view (25). These 25 columns were selected with input from IBM security experts (including some of Kisco’s IBM Champions!) with the goal to provide “the right data” rather than “all data possible – relevant or not”. To that end, there is one other notable change delivered in the new view. The “check_any_authority” column in the authority_collection_fsobj view would indicate a “security pre-check.” This is a kind of “low cost” check that is used to verify whether the user has any authority whatsoever to the target object, and is generally followed up with a “proper” authority check. These “check any” entries can be misleading, or at least confusing. When using the new authority_collection_ifs view this column is removed and any such “security pre-checks” are omitted from the results. This allows the security researcher to focus on the data that can truly tell us something actionable, while avoiding being sidetracked by a “red herring”.
When all is said and done, authority collection is an incredibly powerful tool for anyone responsible for IBM i security. It allows us to take a data-driven approach to security remediation. It arms us with the facts that we need to make informed decisions and implement the principle of least privilege.
Contributed by:
Steve Riedmueller
Director of Security Services
Kisco Systems
RELATED POSTS
BROWSE KISCO U
PRODUCT CONTENT