RE: Installing 3rd Party Software using QSECOFR?? -- MIDRANGE-L

CHGDSTPWD is one command also requires use of the actual QSECOFRprofile - attempts to use this command with a SECOFR class profilewith all special authorities will be rejected with the message. Evenattempting to swap the user profile programmatically using the swapprofile API will not work.

So if you forget your QSECOFR password and then want to re-enable SSTso you can use it during a manual IPL......

The recommendation not to use QSECOFR operationally also reduces thetemptation for the profile to be customised in such a way as to makea recovery more difficult. I seem to remember ages trying to recovera machine where the QSECOFR profile had had an initial program addedto it to provide a menu, among other things. Unfortunately theinitial program was in a user library that had not been restored yetwhich gave me some trouble when trying to sign on as QSECOFR in orderto start the data restore process.

I've seen a lot of sites where the QSECOFR profile has a jobdescription that lives in an application library - a practise I don'tlike for the reasons stated above, but also because my preference isto not have production libraries in the QSECOFR library list (or evenany SECOFR class profiles used for admin) unless they are added. Itseems to me that it reduces the possibility of a disaster at leastmarginally when the profile is in use.


Regards
Evan Harris

At 02:41 p.m. 16/06/2006, you wrote:

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 notdefending various rules from clueless auditors in that case, butonly pointing at the directions things have been going.
QSECOFR, though, is indeed a special case. There are aspects ofQSECOFR that are unique such as the ability to logon at the consoleeven when disabled or the retention of special authorities even whenyou try to remove them. E.g., compare a prompted CHGUSRPRF QSECOFRagainst any other profile and note that a number of attributes forQSECOFR are presented as [*SAME] where all other profiles show theactual 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 fromunexpected system failures during work. The safekeeping of theprofile itself can conceivably outweigh the desire for simplicityfrom not using a secondary *SECOFR profile in heavily audited andcontrolled environments. Today's OS/400 and i5/OS minimizes the riskand might even have eliminated it. There have been circumstanceswhere 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? Itsimply ought to be fundamental policy to use an alternative profileif possible. IBM's directions to "Signon as QSECOFR..." seems to bea reasonable exception.
Barsa Consulting also seems a plausible additional exception. ThoughI'm unaware of a specific requirement to install under QSECOFR,there may be particular multi-system/LPAR/single-hardware-platformoperational tasks that only QSECOFR can do.
For audits, it's often the policy and adherence to that policy thatare most important. I often have no valid idea _why_ some particularrules are involved, but auditors aren't always rational outside oftheir universe.
Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com