QSYSOPR not authorized to RTVUSRPRF
I have a job that runs continually in it's own subsystem under the QSYSOPR profile. I need to retrieve print default values of the user that triggers the job to run. When I use the RTVUSRPRF command or QSYRUSRI API,
I receive USER NOT AUTHORIZED message. I looked at the authorities for QSYSOPR and RTVUSRPRF is not in the list. Is this normal? Is there any way I can get around this?
Software/Hardware used:
Software/Hardware used:
ASKED:
November 9, 2005 9:06 PM
UPDATED:
November 19, 2009 4:19 AM
Our security officer would scream (as well he should) before granting *ALLOBJ authority to a profile. You would be better to do a CHGPGM USRPRF(*OWNER) and make sure the prorgram is owned by a program which has authority to the user profiles -- ie., a profile with *ALLOBJ. This way QSYSOPR does not gain super powers, but can still accomplish the needed task.
Other Answers:
can you send details about rtvusrprf authorities permissions ? (WRKOBJ + display authorisations)
To see other answers submitted to the Answer Wiki: View Answer History.
Object . . . . . . . : RTVUSRPRF Owner . . . . . . . : QSYS
Library . . . . . : QSYS Primary group . . . : *NONE
Object type . . . . : *CMD
Object secured by authorization list . . . . . . . . . . . . : *NONE
Object ———-Object———–
User Group Authority Opr Mgt Exist Alter Ref
QSYS *ALL X X X X X
*PUBLIC *USE X
This looks to be the same for all commands that I looked at.
Is it not so much the authority to use the RTVUSRPRF command as much as it is the fact QSYSOPR is not authorized to do RTVUSRPRF over a certain user. The RTVUSRPRF command requires *READ authority to a user profile to work.
A lot of shops get around this by giving QSYSOPR *ALLOBJ authority.
I agree with not changing the profile. This program will be distributed and I can’t require profiles to be changed. What is striking me odd is the fact that the program object IS owned by QSECOFR, which has *ALLOBJ authority. Anyway, I’ve decided on this work around: Use DSPUSRPRF to an outfile and process the information from the outfile. It adds some overhead, but allows me to put this option in place without changing profiles.
With the clp that runs this job, first change the job owner to QSYS or some other profile that has authority to run the RTVUSRPRF command. Next change the program to adopt authority from the owner’s profile. parms USRPRF and USEADPAUT of the CHGPGM command.
Change Program (CHGPGM)
Type choices, press Enter.
Program . . . . . . . . . . . . PGM > UR1096XXX
Library . . . . . . . . . . . > USERPRODCD
Optimize program . . . . . . . . OPTIMIZE *NO
User profile . . . . . . . . . . USRPRF > *OWNER
Use adopted authority . . . . . USEADPAUT > *YES
I know it’s a late response but…..There is no need for either *ALLOBJ allocation or the use of adopting programs. As pointed out, RTVUSRPRF requires *READ access to the target profile. So give it!!! There is no exposure to *READ access (even for *PUBLIC) on a *USRPRF object. You cannot perform a SBMJOB with said user or perform a profile swap, etc, without at least *USE access and *READ *USE.
There is no exposure to *READ access (even for *PUBLIC) on a *USRPRF object.
For *PUBLIC, the vulnerability is in enumeration of potential user IDs. Strong password protection becomes more important, as does separation of user profile name from individual name and identifying info in the description or other attributes.
Tom