RE: Installing 3rd Party Software using QSECOFR??

midrange-l-request@xxxxxxxxxxxx wrote:

  8. RE: Installing 3rd Party Software using QSECOFR?? (rob)

But I'd argue that audit rules that forbid installation under QSECOFR but 
think it's ok to use any user profile with the following special 
authorities:  *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE 
*SPLCTL; is simply doing "busy" work instead of "real" work.  Much like 
the silly audit rule about limiting your users to one 5250 session when no 
rules are in place about accessing the data with multiple other tools, 
like Excel, simultaneously from the same user.

No disagreement there, Rob. I should emphasize that I'm not defending various 
rules from clueless auditors in that case, but only pointing at the directions 
things have been going.

QSECOFR, though, is indeed a special case. There are aspects of QSECOFR that 
are unique such as the ability to logon at the console even when disabled or 
the retention of special authorities even when you try to remove them. E.g., 
compare a prompted CHGUSRPRF QSECOFR against any other profile and note that a 
number of attributes for QSECOFR are presented as [*SAME] where all other 
profiles show the actual retrieved attribute values (assuming you have 
authority).

Alternative *SECOFR profiles can be more controlled. QSECOFR is not so easy.

A minor area... The more often QSECOFR is in use, the more the risk (admittedly 
very minimal) of object damage to the user profile from unexpected system 
failures during work. The safekeeping of the profile itself can conceivably 
outweigh the desire for simplicity from not using a secondary *SECOFR profile 
in heavily audited and controlled environments. Today's OS/400 and i5/OS 
minimizes the risk and might even have eliminated it. There have been 
circumstances where a damaged (not just *DISABLED but damaged) QSECOFR was 
trouble though.

And when there's no _need_ to use it? Why use it? Why risk it? It simply ought 
to be fundamental policy to use an alternative profile if possible. IBM's 
directions to "Signon as QSECOFR..." seems to be a reasonable exception.

Barsa Consulting also seems a plausible additional exception. Though I'm 
unaware of a specific requirement to install under QSECOFR, there may be 
particular multi-system/LPAR/single-hardware-platform operational tasks that 
only QSECOFR can do.

For audits, it's often the policy and adherence to that policy that are most 
important. I often have no valid idea _why_ some particular rules are involved, 
but auditors aren't always rational outside of their universe.

Tom Liotta