Ok, since I think I was the one starting this I think a clarification about the reason is in place :) The 'problem': We need to read huge amount of data using a program on zLinux, but it needs access to the files. We could use ftp, but due to the huge amount of data, most of the costsaving is eaten up by ftp-cpucycles in z/OS :( And it takes time.
If we could access the actual disks or files directly from zLinux it would really cut the cost here. In that case it is some dedicated volumes, scheduled and documented z/OS jobs. And about the mvsdasd program, it works like this: At the outpointed dasd volume it search for a file with a specified name, it must be there and it is a z/OS std seq file. It is created in z/OS and protected by RACF/ACF2. That file should contain names of files on that volume that mvsdasd is allowed to read. I think this makes it secure and auditable enough. But I haven't had the spare time to have this one working yet. For the moment we test to copy files from z/OS to z/VM CMS-files (tracable and auditable) and then read it from zLinux. /Tore _________________________________________________ Tore Agblad System programmer, Volvo IT certified IT Architect Volvo Information Technology Infrastructure Mainframe Design & Development, Linux servers Dept 4352 DA1S SE-405 08, Gothenburg Sweden Telephone: +46-31-3233569 E-mail: [email protected] http://www.volvo.com/volvoit/global/en-gb/ -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Alan Altmark Sent: den 9 november 2011 05:44 To: [email protected] Subject: Re: mvsdasd On Tuesday, 11/08/2011 at 10:49 EST, Richard Troth <[email protected]> wrote: > Stop calling this a security problem. (but see below about the conf > file) The security point for virtual machines is devices. If the > device is available, then whatever the guest does is okay by > definition. No, it's not. It may be ok by *policy*, but not by *definition*. For example, if the volume contains cardholder data, PCI applies and "strong access controls" are required and all access to the cardholder data must be logged. If you have two logs, then you must have an automated way to reconstruct who accessed the cardholder data. > Just because the current crop of security weebles don't "get it" does > not a true problem make. They are going to have to figure out > virtualization eventually. (Maybe compare MVS vols to USB sticks? > Would the light bulb come on then?) If the security police don't want > the disk (or flash drive) read and/or reformatted by (eg) the Windoze > box, don't plug it in! Eh? Security controls inhibit you when you DO plug in the USB stick. E.g. configured to ignore USB ports. Don't autoplay. Etc. > If one wants to take issue with the config file being mis-tagged as a > security solution, THAT is a legit beef. It's a doc issue. (Jacob > was on this list a year ago. Guessing he still is, but please, debate > it offline.) But again, it's outside the security model of > virtualization. (Thankfully the name of that dataset does not have > "sec" in it.) I'm not talking about security of the dasd volume -- that's fully covered by z/VM. Rather, I'm speaking of logical controls on the datasets that reside on the volume and the VTOC itself. Of course, if the volume contains only those datasets that the Linux guest is permitted to see, then there's not a logical access issue, BUT the dataset access isn't audited. Any audit on the z/VM side can't be correlated with anything on the z/OS side. IF these datasets are specifically constructed for Linux's use, e.g. as a pre-boot configuration manager (a la CMS), then the audit issue may be able to be ignored. This is an example of a having a problem (Linux pre-configuration management without z/VM) that mvsdasd can solve. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
