Re: Security Question

Not odd really. To what a /system operator/ is authorized, is not static across every organization; not even from one operator to another on the same system. Similarly there would unlikely be any expectation that USRCLS(*PGMR) would effect that every compiler and tooling or serive task that a /programmer/ _might_ perform would be automatically available [to all *PGMR types]? Only the special authority *ALLOBJ eliminates the requirement for a user to either have or adopt necessary authority to access resources.

The USRCLS(*SYSOPR) establishes *only* that:
- SPCAUT(*USRCLS) will effect SPCAUT(*JOBCTL *SAVSYS)
- a feature explicitly requiring User Class *SYSOPR is enabled [made visible on a menu if that user class attribute is checked, but typically only when sufficient authority to the /command/ or feature is *also* available -- UIM menus typically use just a command authority check]

Neither the user class *SYSOPR nor the special authorities *JOBCTL and *SAVSYS can circumvent [or override] object authorities. No User Class specified, will effect the automatic grant of any private authorities; i.e. granting authority is still required to allow access. As others have alluded, the GRPPRF(QSYSOPR) would implicitly grant authority to the created user via its group profile, to those objects to which the user QSYSOPR is already authorized privately.

If on a prior release the system had been customized to GRTOBJAUT QSYS/PWRDWNSYS *CMD SomeUser AUT(SomeValue), then if the system was migrated versus upgraded on the same disks, such customizations would have been lost due to improper system management. That is, after an install, scripted customizations should be performed again. Noting however that in most cases, authorities to commands would persist; i.e. in standard slip-install. Only when a release explicitly changes the authority would a customization be lost; thus an error in proper system change management may not be visible until that release. However the explicit change to *EXCLUDE for *PUBLIC to the PWRDWNSYS *CMD has been occurring every slip install since V3R2M0. FWiW I am of the opinion that any such change is a defect when not removed after N+2 onto the release in which it was first added, simply because the forced loss of customization [even if only to *PUBLIC] is forcibly lost and then customization must be performed again in a post-install system change management script -- and why should it be changed twice versus once?

Regards, Chuck