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?
>> 
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.