RE: Dumb adopted authority question

David,

> If I am signed on as QSECOFR, and run a program (ILE CL) that is owned
> by a normal user and has USRPRF(*OWNER), what is the programs effective
> authority?  QSECOFR or the users?

Adopted authority is always additive to the authority of the current
thread/process. But when it is not needed it is not used. The answer to
your question above is: QSECOFR authority plus adopted user authority gives
your program QSECOFR authority.

Tom Liotta wrote on 02/22/2005 05:07:38 PM:
> Now, AFAIK, QSECOFR special authorities cannot be changed
> (Svalgaardisms notwithstanding, etc.) and *ALLOBJ short-circuits
> user authority checking for an object. Hence, it would seem that the
> problem ought to be at a point after the first profile swap has
> taken place. I.e., QSECOFR authority should be sufficient,
> regardless of USRPRF(*OWNER), to swap to some other profile.

This followed my previous line of thinking; but Tom's note caused me to
remember the *NOPWDCHK and (new in V5R3) *NOPWDSTS special values for
QSYGETPH. Is it possible that the problem is not that the other security
officer profile does not have *USE authority to QSECOFR, but instead is
that the profile is disabled or its password is expired?  It that is the
case then you will have to specify  *NOPWDCHK or  *NOPWDSTS instead of
*NOPWD for the password parameter on QSYGETPH.

Ed Fishel,
edfishel@xxxxxxxxxx