For any user who doesn't have class C, Set priv is not a security concern at all. They cannot go outside their directory classes. All they can do is remove an existing class or restore it. the real security concern is the Directory Class C, not the user's ability to use SET PRIV. One must be very cautious about granting that privilege class.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Scott Rohling Sent: Thursday, February 04, 2010 12:07 PM To: [email protected] Subject: Re: Hi everybody Yes - as you parenthetically alluded to - allowing SET PRIVCLAS is a feature you have to enable.. some customers see a command like SET PRIVCLAS as a security breaker.. It depends on how strict and how much 'separation of duty' is built into their security policies. Anyone with class C and SET PRIVCLAS feature enabled is essentially an all-powerful user, period. Scott On Thu, Feb 4, 2010 at 12:12 PM, zMan <[email protected]<mailto:[email protected]>> wrote: On Thu, Feb 4, 2010 at 1:44 PM, Schuh, Richard <[email protected]<mailto:[email protected]>> wrote: It isn't a matter of trust, it is a matter of minimizing the risk of an accidental SHUTDOWN. Here MAINT does not have class A; however it does have class C. That allows it to use the SET PRIV * +A in order to issue class A commands such as Q CPDISKS, CPRELEASE and CPACCESS. By requiring that extra step of the SET PRIV, it heightens the awareness of the person to the fact that they now have extraordinary capabilities and responsibilities. Exactly. I'd argue that "best practices" (a term I hate) has even MAINT doing a CP SET PRIVCLAS * =BEG (unless that's disabled, of course) in its PROFILE EXEC, and then using a CLASS EXEC for privileged commands: CLASS A SHUTDOWN
