I somewhat agree with you Alan (and these minidisks are indeed already in the HCPRww so that CP doesn't even consult RACF for a RR link. As for these passwords: there is no real convention thet the passwords msut be "monyyyy", they can be anything that explains the content/level. It would be more secure without them, but I prefer knowing what level is on an MDISK and avoid VM (or VM application) outages due to mistakes as I consider the risk of someone deactivating RACF (or starting a CP without RACF) much smaller.
You can not my vote to extend the MDISK statement with a COMMENT field that DIRMAINT will always keep with the MDISK card. e.g. a C-like notation (and waw more than 3 words as comment, and no prereq for an ESM) MDISK 019E 3390 1735 190 VTE521 MR ALL // Fixes for CA products DEC2007 2008/2/8, Alan Altmark <[EMAIL PROTECTED]>: > On Friday, 02/08/2008 at 10:06 EST, Kris Buelens <[EMAIL PROTECTED]> > wrote: > > If you are lucky enough to have an ESM like RACF, what means the LINK > > checks are not password based, you can work the way I set things up > > for my client: use the minidisk passwords as descriptive comments. > > Here an extract of MAINT's entry: > > MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006 > > MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006 > > MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006 > > MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006 > > MDISK 0CF1 3390 587 80 VTERES RR > > MDISK 0CF2 3390 408 80 VTEBKP > > MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007 > > MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007 > > MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007 > > Side remark: > > As one can see, we set the read password to ALL for these "general > > public" minidisks. This way if we'd be forced to IPL without RACF, > > people would still be able to LINK RR without password (but, even > > though I still have a CP nuc without RACF on CF1, we never had to use > > a CP-without-RACF in the 19 years we run with RACF > > Since they are public and you don't require auditing of their access, you > can add them to RACF's GLBLDSK macro to prevent RACF from protecting or > auditing read-only access. > > Unfortunately your use of the password fields in that way creates a > security exposure. If the system does come up without RACF, OR if the > VMMDISK were deactivated, anyone who knows your naming convention can get > r/w access. If, in 19 years, you never had to run without RACF, then I > think the risk of the security exposure exceeds the risk of a RACF outage > sufficient to make you run without RACF. > > Alan Altmark > z/VM Development > IBM Endicott > -- Kris Buelens, IBM Belgium, VM customer support
