Comments on: QSYSOPR not authorized to RTVUSRPRF

By: tomliotta

tomliotta — Thu, 19 Nov 2009 04:19:09 +0000

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

By: paulthomas

paulthomas — Mon, 14 Nov 2005 04:02:54 +0000

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.

By: billohio

billohio — Fri, 11 Nov 2005 10:05:42 +0000

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

By: anncyb

anncyb — Fri, 11 Nov 2005 09:21:18 +0000

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.

By: thequigs

thequigs — Fri, 11 Nov 2005 09:04:49 +0000

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.

By: waltz400

waltz400 — Thu, 10 Nov 2005 12:12:11 +0000

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.

By: anncyb

anncyb — Thu, 10 Nov 2005 08:38:44 +0000

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.