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
