I would assume that if it's important enough, you could write a program (or find one) that will take a password, encrypt it, and store it in a file. Then your script could use your program to decrypt the password and store it in a variable. Then your script could call your dsmadmc command with -pa=$password.
Realistically, I've found that almost all of the people with root access to a server are trusted by their employer. Additionally, if you disable remote login as root, so people can only su to root, you can realistically track who has access to that password. By putting the password in clear text in a file that's only readable by root, I feel you've implemented a realistic level of security. If you're a government, or if security is ultra-necessary, or possibly you have legal requirements, I don't see why implementing your own password encryption scheme wouldn't be feasable. As an aside, if you store the password in clear text in a root-only file on the same server your TSM server lives on, you're really not losing any security because anybody with root access (see the above paragraph) can just come along and start TSM in the foreground and do whatever they like, such as registering an admin with system authority. Just as TSM admins have to be trusted individuals, your OS people have to be trusted as well. Alex Paschal Storage Administrator Freightliner, LLC (503) 745-6850 phone/vmail -----Original Message----- From: StorageGroupAdmin StorageGroupAdmin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 13, 2002 1:49 PM To: [EMAIL PROTECTED] Subject: How do you secure the passwd in a TSM admin command run a via batch script I would like to run a UNIX script that issues a series of TSM commands that require SYSTEM access rights ( DEFINE MACHINE & INSERT MACHINE). The problem I have is that I am forced to have a TSM ID and PASSWD within the script or in an input file therefore accessible to a multitude of people. Firstly, I have trouble understanding why these two commands require SYSTEM access. Secondly, I would like to see the TSM security re-worked so that either; specific functions could be added and removed from the generic access class as required (ie Operator could be extended to allow the INSERT MACHINE cmd). OR An individual users access could be extended to include / exclude commands. For those with mainframe / DFSMShsm knowledge, what I am imagining here is that a PATCH like command that could be applied to the aplication to redefine the required access. Since the TSM developers also read this discussion group I am hoping enough people will agree and comment as such so to plant the seed of thought with the developers. I also would appreciate if anyone could suggest a method to secure the password from prying eyes. I can only think of making the file hidden but that has it's own problems. I imagine that similar situations will become more common place as task dependancies on separate server grow and the scheduling of tasks must be removed from the specific application (such as TSM) to a centralised scheduling system. For example, a file must successfully be written on server A before the TSM backup starts. Peter Griffin Sydney Water ----------------------------------------------------------- This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and then delete the original e-mail. -----------------------------------------------------------
