In a recent note, Bob Rutledge said:
> Date: Sat, 20 Aug 2005 10:30:19 -0400
>
> Paul Gilmartin wrote:
> >
> > o The default OMVS UID should, by default, be defined in base
> > MVS systems.
> >
> > o That definition should be built in in such a way that ace admins
> > might be able to change its value, or its shell, but never to
> > delete it.
> >
> > I wonder what Walt F. says?
>
> Sorry, I should have mentioned that the security softare is CA-TSS. Not
> Walt's
> problem!
>
Somewhat an afterthought, but as I envisioned it, by "base MVS"
I meant the kernel, outside any *ACF* product. Something like:
DUB: Query security product for user's UID
if failure then query security product for default UID
if failure then UID=-2 /* customary value for "nobody" */
The intent is that the admin can supply a default UID if desired;
if not, the system will use its builtin value.
> library and the stack is Interlink/Sterling/CA's. Makes problem determination
> more challenging.
>
Also makes sequestering of the default OMVS UID more challenging.
Obviously, if a third party ISV supplies a functionally equivalent
replacement for OMVS, not just for TCP/IP or RACF, that party would
control the behavior of the default UID. The risk is low.
Regard OMVS nowadays as comparable to JES. A site can't just
turn off JES if it chooses to operate without it. Nor can a
site deny selected users access to JES facilities. (Imagine
JES querying *ACF* to determine that each requesting user has
a JES segment in his *ACF* definition; yet that's how OMVS
operates.) (And I am aware of no ISV replacements for JES.)
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
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
