Re: Adopted authority

On 26-Jul-2016 10:55 -0500, Tim Bronski wrote:

On 7/26/2016 5:47 PM, CRPence wrote:

On 26-Jul-2016 09:47 -0500, Tim Bronski wrote:

Rather than hijack the current thread on authority adoption I'll
start afresh...while we're on the topic does anyone know of a way
to find out if the current program is working with adopted
authority or would I have to walk the stack back?

[…] Generally knowing of adoption is not relevant outside the
program itself; i.e. the current program /knows/ if the thread is
adopting, based on the effects of the [in]ability to resolve to an
object that requires the adopted authority. That is to suggest,
either the program fails with an exception x0A01 [MCH1001] per
authority is unavailable, else the program gains privilege via the
adopted authority. […]

More specifically, I'd like to know in a program the name of the
profile whose authority I'm adopting - if any.

I suppose inquiring back in the stack; materializing\retrieving the attributes of the programs could help to infer. What will not be known is definitively from which user the OS obtained the authority; even if testing of one user's authority the object is verified, does not mean all of the authorities available were garnered from that user.

So I do not really see the point, generally; if designed, then the program will either have the authority by adoption, or not.

But if one were insistent, there is:

Retrieve User Authority to Object (QSYRUSRA) API
[http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/qsyrusra.htm]
"…
If previous programs in the program stack adopt their owner's authority, the adopted authority for the current program is the accumulated adopted authority from all other programs in the program stack that adopt authority. Adopted authority is only valid when the user specified is *CURRENT. If a path name is specified, adopted authority is not used when accessing the path object.
…"

I need to test for certain special authorities before
attempting/reporting certain operations. Testing the effects of not
having the authority is a least favored method.

Coding with a presumed-success is generally more efficient and avoids concurrency issues: • don't test for authority, and if not authorized, then fail • test first for authority, and if nearly simultaneously the user was granted authority, the application might appear to falsely report the capabilities. The former also reveals when a user attempted to do something they probably should not have, by ensuring a T-AF is generated, whereas the latter depends on the application [optionally] logging the effect.

I can retrieve the current user profile but that doesn't give me the
full picture if I'm adopting authority from the caller.

I am still not clear; probably a specific example would help clarify. Regardless, that aforementioned API might be of value.?