RPGIV @ Work

A unique site for RPG and System i Lovers


Hi, this site will provide all what you need in System i and RPG developments.

My Name is Chamara Withanachchi, System i Expert and RPG Developer. And in the field for last 11 years.

I hope you will find lot of valuable information from this site

Top Five Security Questions Print E-mail
User Rating: / 0
Written by Chamara Withanachchi   

#5 – What is Primary Group Authority?

Primary group authority was created to accommodate the concept of group authority in UNIX. It was added to OS/400 when IBM added support for the Integrated File System (IFS). All of these functions were added to facilitate porting UNIX applications to run on OS/400. Primary group authority can only be given to a group profile and only one group profile can be an object’s primary group. Primary group authority is similar to a private authority granted to a group profile. The biggest difference is the primary group and its authority are stored in object’s header (versus with the user profile for private authorities). Primary group authority is checked before any private authorities the group may have; therefore, you’ll see a slight (and I do mean slight) performance gain when using primary group authority. The gain is so small it’s not worth the time it would take to change your security configuration.

#4 – What Authority is Required to Run (Name Your Favorite Command)?

Appendix D in the Security Reference manual lists all of the IBM i CL commands, along with the authority needed to run them. It lists commands by the type of object they act on (e.g., user profiles, jobs, etc.). At the end of each command table are notes listing additional requirements (e.g., users running the user profile commands must have *SECADM special authority).

#3 – Isn’t Adopted Authority Dangerous and Shouldn’t I Avoid It?

Adopted authority lets you temporarily grant users the capability to perform a task without assigning them the authority permanently. If you blindly compile programs owned by QSECOFR or some other profile without examining them to determine their function, then yes, adopted authority can be very dangerous and can be used to subvert the security on your system. However, by default, not just anyone can compile a program that adopts a powerful profile. Used carefully, adopted authority can eliminate the number of users required to have special authorities. For example, many IBM i clients write utilities—CL programs that adopt a profile having *ALLOBJ and *SECADM special authorities—to perform password resets. This way, the help desk can reset passwords when users forget them, but help desk personnel don’t need to have special authorities or be specifically authorized to the profiles to perform the task.

#2 – Is Group Authority or User Authority Checked First?

The authority checking algorithm checks the user, then the groups and then *PUBLIC authority. Specifically, it looks first to see if the user has *ALLOBJ, then for a private authority and then for the user’s authority to the authorization list securing the object (assuming there is one). If no authority is found at the user level, the user’s groups are checked—first for *ALLOBJ, then primary group authority, private authority and private authority to an authorization list. Finally, if no authority is found for the user or the groups then *PUBLIC authority is checked.

And the #1 question I’m asked is...

#1 – Are Group Profiles or Authorization Lists Better?

It’s not a matter of one being better than the other. It’s a matter of using the one that makes the most sense for the problem you’re trying to solve. If you have several profiles that all require the same authorities, you’ll want to put them in a group and authorize the group. Additionally, group profiles are the way to implement role-based access on IBM i. Create a group to represent a role, authorize the group according to the tasks required by the tasks this role must perform and then add the users who perform this role to the group.

Authorization lists let you authorize numerous objects in the same way. For example, if users need the same authority to several files, you can secure the files with an authorization list, then grant the users authority (for example *USE) to the list. The user now has *USE authority to any file secured by the authorization list. I often use a combination of authorization lists and groups. For example, an accounts receivable application has a set of files the accounting manager role is allowed to download. I secure those files with an authorization list, then grant the group profile representing the Accounting Manager role *USE authority to the authorization list. When another person is hired in that role, you can simply add them to the Accounting Manager group and they automatically have authority to the files they need.

<Previous   Next>