Patrick O'Keefe wrote:
On Mon, 13 Nov 2006 17:28:47 +0100, R.S.
<[EMAIL PROTECTED]>
wrote:
...
As you wrote it's because auditors want it. I understand your point,
however I'm curious whether there's any real reason.
I strongly agree with John on this. Even if no auditors were involved,
giving a person UID(0)is giving far too much authority than is needed.
To do that is to give the person a gun and paint a target on his or her
foot (or on the whole shop's collective foot). Requiring setting SU in
TSO or doing a setuid(0) or seteuid(0) in batch hopefully puts the user
in "be careful" mode.
I dare to disagree. No, I STRONGLY DISAGREE!
What are your procedures for RACF SPECIAL user ? Are they so restrictive?
What about storage administration ?
I remember a shop with few newbies working as storage administrators. I
protected "ICKDSF" by DASDVOL activation. They didn't get ALTER to
DASDVOL profiles. Instead, they got CL(SURROGAT) STGUSER.SUBMIT
ACC(READ) and STGUSER has ALTER. So they were able to use ICKDSF, but
not screw something up using ISPF "oops! typo navigation".
SU everytime is similar (IMHO worse!) method for USS "newbie
administrator", but it is unneeded for experienced person who need
UID(0) everyday.
Last but not least: UID(0) on z/OS Unix is less than on any other Unix
implementation. However AIX/HP-UX/Solaris/whatever administrators use
UID(0) for everyday work.
My $0.02
Regards
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
