Allow finer grained 'Adopt Authority'

This idea will allow ISVs and other to help close security exposures related to programs that adopt authority. 
 

Currently a program can be set to USRPRF(*OWNER) to have it adopt authority.   Different programs within an application have needs for access to different objects via adopted authority and also at times need full *ALLOBJ authority for legitimate reasons.   If an application has varying needs for additional authority for different application actions, the normal approach is to have a application profile which has a superset of all authority needed in various parts of the application.   The alternative would be a separate user profile for each use case that needs a different set o of authority.   Examples would be that some functions only need access to the application's internal files, other functions may need to perform OS security related functions, and still others may need arbitrary access to objects (*ALLOBJ). 

The idea is to introduce a new setting for programs and service programs  USRPRF(*LIMITED).   These programs will normally run with no adopted authority, but will have the authority to 'ask' via a new API for access to specific objects that the owner of the program has access to.    The API would also allow the program to retract that authority.   This limits the scope of the use of adopted authority to exactly what the programmer needs and explicitly asks for.   In fact, if the owner has *ALL access to an object, ideally the program could ask for only *USE authority if that is all that was needed-- this would provide even more granularity, but is not required. 

This will help prevent accidental or malicious authority elevation via defined user exit programs (whether IBM registered exits or application defined mechanisms) or via *LIBL exploitation or via user input referencing an arbitrary object he does not have access to, but the application failing to make an authorization check. 

A more simple but less powerful approach would be to allow the program to turn the adoption of all adopted power on or off without referencing a specific object.  This can be sort of done today with MI instruction MODINVAT, but it only applies to called code and this would be difficult to use in practice to dynamically turn on/off adopted authority in the current invocation level. 

The above is one way of implementing the idea, but others may be appropriate also.  The general idea is to provide a means to allow a program to limit the scope of the adopted power.