Re: Encapsulating Stored Procedures with adoptedauthority

FWiW the "Use adopted authority" is meaningless in whether authority is adopted from the owner. That value applies to whether previously adopted authority, whatever authority was adopted from prior [stack] invocation levels, may be suppressed; i.e. "Suppress prior adopted authority" might have been a better moniker. So, only the "Owner" and the "User profile" values are of interest. The program "was created" by the expected user profile, but whether the program "was owned" by the expected user profile as presented by the DSPPGM was left unstated; very important distinction.

Although the user "security administrator" signed on can issue CHGUSRPRF, that is not sufficient evidence of its having *SECADM special authority. That user may only be adopting or instead have its capability come from a [supplemental] group. Does the DSPUSRPRF of that user actually show the *SECADM special authority? Just as *SECADM should be adopted, I believe that is true regardless if directly or from a group; i.e. if the user as *OWNER does not have *SECADM, then does one of its group profiles?

Presumably the error message identifier CPF2292 was origin for the noted text. I expect that *SECADM should be adopted from the *OWNER if not held by the requester; I believe both users could be examined for that special authority, such that if adopted owner did not have the capability, then additionally to check if the requesting user had the capability. I do know that adopted authority is not in effect for the explicit authority required to the specified GRPPRF or SUPGRPPRF, but an error to modify either of those should end with an explicit authorization error versus an error noting insufficient capability due to a lacking /special authority/. Nonetheless, be sure to verify by ?CHGUSRPRF that all [optional] parameters default to *SAME. Also check to make sure there is no validity checking program and that the prompt override program is QSYPRPOP [see DSPCMD CHGUSRPRF], plus ensure that either no exit program is defined [see WRKREGINF QIBM_QSY_CHG_PROFILE option-8] or that is not the cause of the problem. Since the F/pgm [from program] and other details of the error condition were unstated, I can only infer they were directly from the CPP QSYUP of the CHGUSRPRF command versus.

I see no reason the call via SQL would work if the CALL via CL does not; I would be concerned more, for a lack of consistency in that result.

However I know that at one time there was a problem with SQL properly adopting via SQE or CQE, but that was for running as a UDF rather than a procedure, since that distinction would require that a query was being performed. Regardless, be sure that if running on an older release, ensure a DB group PTF level from, at the oldest, mid-year 2009.

Regards, Chuck

Vanderhook, George wrote:

<<SNIP>> DSPPGM shows the CL to have USRPRF = *OWNER and USE ADOPTED AUTHORITY = *YES. I created this program using a
security administrator sign-on where I'm able to use the
CHGUSRPRF command. However, when I sign on as a regular user,
and call the CL, I get a message in my joblog saying, "*SECADM
required to create or change user profiles." I'm calling the CL
directly so I'm not sure what could be happening. Does the
system look at the authority on both sign-ons when it does its
authority check, or is it just the owner of the CL?

My intentions with this are to put make this CL a stored procedure which is called via a Call statement through a JDBC connection. Could this possibly not work from the iSeries but, instead work from the JDBC connection?