You can name it /.a, an innocuous name (ooops. well, not anymore) that won't
appear in casual
ls listing because of the leading dot.
Then run chmod 600 so onlyy the owner can read it.
Then scripts can say "dsmadmc -id=admin -pas=`cat /.a` ..."

----------------------------
Mr. Lindsay Morris
Mr. Lindsay Morris
CEO
Applied System Design
www.servergraph.com
859-253-8000 ofc
425-988-8478 fax



> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> StorageGroupAdmin StorageGroupAdmin
> Sent: Wednesday, February 13, 2002 4:49 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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.
> -----------------------------------------------------------
>