3) *OBJMGT cannot come from adopted authority.
[ GRTOBJAUT OBJTYPE(*USRPRF) AUT(*OBJMGT) ] can run under adopted authority. So, even if CHGUSRPRF may check to see if *OBJMGT exists when attempting to alter group profiles and refuse to make the change if the authority isn't available, the same program that runs CHGUSRPRF can run GRTOBJAUT first.
Then when CHGUSRPRF is encountered, the appropriate authority is already there.
Thanks for the feedback. In order to use chgusrprf and update supplemental groups, *OBJMGT and *SECADM are required and adopted authority cannot be used. My task was to provide “regular users” the ability to grant and revoke supplemental groups. I had coded a similar solution several days ago, but found in testing that a “regular user” could not run the program.
I advised my manager of this caviot before starting the project and just completed 4 days of coding/testing various alternative and wasn’t able to permit “regular users” to control supplemental groups in an interactive environment.
I tried adopted authority and submitting a batch job running under an ADMIN profile. Nothing made it past executing the CHGUSRPRF command. The batch job failed stating the user didn’t have authority to the ADMIN profile.
Today I recommended the interactive process create a datafeed via data queue or database. Then a program with appropriate authority could receive the information and grant the appropriate access.
The managment response is to have support grant the supplemental groups when creating profiles.
I know this won’t be the end of it….so I’m still look for a viable solution.
If anyone know of an interactive method to manipulate supplemental groups that doesn’t require special authority, please drop me a line.