This is the second time around on this question?  Is anyone interested in
this issue?

Those of us that are trying to share our 3494 libraries and some of us
having done so successfully have recognized that the "mtlib" command and the
lmcpd interface have no security to prevent improper accidental or malicious
actions.  Once an open systems host has been defined to the library that
host can change the categories of the tapes, mount them in what ever drive
it wishes, use tapeutil to do whatever including read, write, erase the tape
if the host has access to a tape drive in the library.

As part of Share and a customer I have taken an interest in defining a
requirement for IBM to eliminate this issue.  There are a number of
approaches that IBM could take, but the easiest, simplest, and most cost
effect from my point of view is to implement security in the library manager
to register ranges of tapes to hosts (multiple if you like).  Register the
drives the host can manipulate.  And, to implement a password token with
automated refresh and manual reset facilities that the host has to pass with
each lmcpd (mtlib) request.  However, this would not change the way any
application (backup product) uses the library or the ability to say a system
has unlimited access ("*" for all tapes or drives).

This function would be selected by the customer as to whether to turn it on
or not.  Once on, each host will have to have a temporary password set in
the LM and issue a new parameter (-P) on the mtlib command with the
temporary password to prime the password control information for a host into
the ibmatl.conf entry for that library for this host.  At that point the
system will go into a password generate mode where it can change the
password in a two phased commit process every "n" days (customer
selectable).
Each lmcpd request will have the imbedded generated password token.  There
are certainly other security encryption schemes that could be used to
protect against snooping, but that is the least of the problem right now and
would be only nice to have. At least now the host has to pass an
authorization to do something to the tapes.

The LM GUI interface would have some extensions to the host definition
screen to support defining what a host could manipulate.  One area that
would be nice is to define volume or drive groups and just register the host
to the volume or drive groups that you wish it to be able to manipulate.
That way a change to the group to add a new drive would not require every
host to be updated, same for volumes.

This is how it would affect the open systems hosts.  Commands from an
invalid host (reverse IP lookup) rejected outright with the same error that
an invalid library gets today.  Requests that have invalid passwords would
have the same thing happen to them.  Requests to manipulate a tape or drive
that a host does not have access to will be rejected.  Inventory of drive
and library query functions will operate as today because backup products
issue requests for this stuff and could be affected if it were not left the
same.  Inventory of tape volumes will mask out volumes not belonging to the
host (this is nice to have).  The insert function will only notify the hosts
that have been registered to the volume range, meaning if no host will get
the information if none are registered.  And, if a range is registered any
tapes in FF00 status will get notified to the newly registered host.

How do we want to change this for open systems?  We need to ask for what is
a business critical need so IBM will do it.

How do we want the mainframe to play here?  The mainframe does not use the
lmcpd interface, yet.  Customers have asked for mtilib on the S/390 so that
they can do the inquiry functions or fix problems with open systems tapes.
I suggest that the same be true of the S/390 requests.  However, right now,
I suggest it be simple, allow a S/390 definition to the library for all
S/390s and let them continue to manage their security external to the
library among themselves.  At least this would prevent the S/390 from
messing with open systems tapes and drives.  If the mtlib function is
created for S/390 down the road it will just work the same way as the
functionality for the open systems.

The potential benefits here are significant.  Sharing tapes between
platforms without exposing things that you do not want could become a
reality.  Sharing drives becomes much more secure because you can limit the
pools of drives a host can manipulate.  Using a library to support multiple
internal customers/users now becomes a possiblity.  And, the potential for
an integrity train wreck waiting to happen were some critical data gets
accidentally destroyed is eliminated.

If the function for insert is done the way suggested above you could just
load your library with a bunch of tapes and leave them in FF00 status.
Define a new range when a host needs some more tapes and those notifications
get sent to the host for it to do what it should (just an idea).  The other
piece that I have always wanted is an insert script execution to allow us to
identify for a library in the ibmatl.conf the name of a script to execute
when a tape is inserted into the library.  That way a TSM customer could
script the label function, range checking, assignment of tapes to storage
pools directly, etc.

Please let me know what you think.  IBM has not committed to do anything.
They have heard from customers on this issue but no formal requirement has
ever been submitted.  I would like to submit one by April 19th.  But, the
more input I can get the better.  This requirement will also be submitted
through Share.


Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180