Re: Odd security issue with adopted authority

On 14-Sep-2015 10:41 -0600, Jim Franz wrote:

This has worked for several years, and no recent program change,
PTFs, or profile change that we can detect. It worked up to Friday
morning...

Looking at an issue where a program that adopts authority
(User profile . . . . . . . . : *OWNER)
and owner has *ALLOBJ and *SECADM is executing a CRTUSRPRF and not
authorized to the Group Profile of the user to be created. This is
a client job (C#) calling my program

Job: QZRCSRVS User: QUSER Number: 008237
Message ID . : CPF9802 Severity . . . . . . . : 40
Message type : Escape
Date sent . : 09/14/15 Time sent . . . . . . : 11:4
Message . . . . : Not authorized to object GR_NONXYZ in QSYS.
Cause . . . . . : You do not have the correct authority for
object GR_NONXYZ in library QSYS type *USRPRF.
Recovery . . . : Contact your security officer or the object
owner to obtain the correct authority and try your request
again.

So does the current-user for that job have *OBJMGT authority to the
user profile (*USRPRF) object named GR_NONXYZ, as obtained from
something *other than* adopted authority? Probably not. And if not,
then the error is correct. The /required/ authority, according to
the *Restrictions* from the command documentation, is:
[http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/cl/crtusrprf.htm]
" • Change (*CHANGE) and object management (*OBJMGT) authorities to the
group profile and supplemental group profiles (if specified)."

But then additionally, specifically for the Group Profile (GRPPRF)
and Supplemental Groups (SUPGRPPRF) parameters, there is the additional
note [seen in the same\above doc link]:
"The current user of this command must have object management (*OBJMGT)
and change (*CHANGE) authority to the profile specified for [this]
parameter. The required *OBJMGT authority cannot be given by a program
adopt operation."

Why that additional *restriction* that the authority for the group
profiles can not be _adopted_, is not included [*also*] in that
above bullet, I have no idea. Although the TechNote document is
helpful [as that document therefore can be found, by searching on the
error message identifier and failing command name], the actual
documentation could be made clear(er) IMO. Anyone who cares, e.g. the
OP, might desire to suggest [by submitting an electronic comment to
the docs] that the information about the specific restriction with
regard to the use of adopted authority for the *OBJMGT right, like
already is described in both the TechNote document N1013328
[www.ibm.com/support/docview.wss?uid=nas8N1013328] and [but] buried
in the documentation of the xxxGRPPRF parameters, should be included
*also* under the general *Restrictions* for the Create User Profile
(CRTUSRPRF) [and Change User Profile (CHGUSRPRF)] command
documentation.

This still works in out test partition but not in production.

Probably "This" is not identical, despite the implication; the
request or requester is different, and\or there are differences
between the LPARs. The difference may be [and probably is] object
authorities, rather than the attributes of the profiles. Possibly
QUSER on the test LPAR was incorrectly modified to have more than
SPCAUT(*NONE), or the QUSER on the test LPAR explicitly has the
necessary authority to the group profile.

We allow a select group of users, outside of IT, to manage outside
users. V7R1.
Owner has *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE
*SPLCTL

As already described above: That the owner of the program [from
which the authority is adopted to issue CRTUSRPRF] has SPCAUT(*ALL),
is moot, for accessing the [supplemental] group profile(s) being
referenced on the Create User Profile (CRTUSRPRF) request; i.e. the
[*current*] user running the program needs to have explicitly granted
[or have via *GROUP authorities], the *OBJMGT authority to the
[supplemental] group profile(s). That is because the OS explicitly
prohibits the /adopted/ authority [from the owner of the program] for
the Test Authority (TSTAU) that is issued against those objects,
specifically when processing the CRTUSRPRF command or the CHGUSRPRF]
command.