When it comes to user permissions on your IBM i, you can be sure of one thing: Unless you've specified otherwise, users will have free range to do whatever they please.
The graphic included on this page is intended to provide a high-level visual representation of the IBM i Authority Search Order. Except for the IFS, any time an object is accessed, your IBM i will execute this sequence of steps to determine whether or not the user has authority to do so.
As you can see, the system first checks the level of authority of the user. If none is found, access is then granted based on the cumulative authority of group membership, *PUBLIC, and possibly – the program owner.
*NOTE: Adopted Authority is an additional configuration on the program. If not configured, the search will end with the test for *PUBLIC authority
If the entire search order has been executed and no permissions have been identified, access will then be denied.
Restricting access to sensitive information and minimizing user privileges is not the responsibility of the operating system. By default, the IBM i makes it as easy as possible for all users to access information freely and perform any and all functions that could be relevant to their jobs.
What the Authority Search Order Looks Like on Real Systems
Take Jane for example. She’s an IBM i system administrator at a major finanical institution. USERA –who leads a team of researchers within her organization – is attempting to access a database file containing sensitive customer data to assist in pinpointing buyer trends. Although the intent is well-meaning, those with USERA’s job title are not supposed to have access to such sensitive information.
The authority search order first tests for *ALLOBJ Authority. Jane understands the power of *ALLOBJ authority and has limited assigning it to only a couple of users, of which USERA is not one. USERA’s request is then tested for private authority. Since no access has been explicitly granted, USERA is then tested for group membership.
Jane has explicity ruled that those of USERA’s job type should not have access to this object. However, USERA is a part of a number of groups. The authority search order procedure then checks the other groups that USERA is a part of and finds that the MANAGER group profile does allow access to the object, thus USERA is given permission to access the object. The process would execute as follows:
- Test for *ALLOBJ authority: USERA does not have *ALLOBJ authority.
- Test for private authority: USERA has not been explicitly granted access.
- Test for group membership: USERA is a member of a group that has authority to the object. Access granted.
If USERA did not have group permissions, the search order would have then revealed there was no *PUBLIC authority to access the object, and the request would have made it to the final test for adopted authority. There, a test is run that deciphers whether USERA is running a program owned by another user that does have sufficient authority. In this case, USERA was given permission to run a program owned by an application profile with sufficient authority and was therefore granted access. This sequence would look like this:
- Test for *ALLOBJ authority: USERA does not have *ALLOBJ authority.
- Test for private authority: USERA has not been explicitly granted access.
- Test for group membership: USERA is not a member of a group that has authority to the object.
- Test for public authority (*PUBLIC): *PUBLIC does not have authority.
- Test for adopted authority: USERA is running a program owned by an application profile with sufficient authority and adoptive authority is enabled. Access granted.
There are many different ways a user under Jane’s supervision could gain unauthorized access to objects or run unauthorized programs. In an era where overprivileged users account for the largest percentage of security breaches and downtime, understanding each possible route for unauthorized activity and operating based on the principles of least-privileged access is more important than ever.
Want to See How Your Access Permissions Compare to Best Practices?
Fortra’s free Security Scan provides a snapshot of your current system security in just a few minutes. You will be able to see exactly where your system is vulnerable, what system values are out of sync with best practices, and what specific measures you can take to improve your security posture going forward.
