McKown, John wrote:
[...]
If nothing else, grant RACF read authority to BPX.SUPERUSER in the
FACILITY class to the people who need it. This will allow them to "su"
for root (UID 0) access as needed. There are a lot of profiles starting
with BPX. in the FACILITY class to allow people to do superuser-like
functions. There are many more profiles in the UNIXPRIV class to also
let non-root people do things.
If a "live person" must run a batch job which demands root, then set up
a SURROGAT profile to allow them to submit a job with the USER=
specifying the id in the SUPERUSER() parameter of BPXPRMxx in PARMLIB.
We __never__ allow an "interactive" user to have UID(0) in their OMVS
segment. Only a very few PROTECTED RACF userids have UID(0). In fact,
there are only two in my shop. There is the SUPERUSER in the BPXPRMxx
member and there is a separate one for the HTTPD server. The only reason
I have two is so that the RACF accesses to non-UNIX datasets is more
controlled for the HTTPD server id. These ids are only used for specific
started tasks such as TCPIP and other UNIX daemons.
IMHO the better idea is to have dadicated user fo BPXPRMxx SUPERUSER. It
should be very limited userid. Not used anywhere.
Daemons should use other userid(s).
BTW: whye the "live person" shouldn't have UID(0) ?
I mean person who really needs it, not everyone.
--
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
