Since this topic of clear text passwords has arisen, I wonder if
anybody knows whether or not there is/are any outstanding
requirements or enhancement requests for Kerberos support within
TSM. This would be handy both in the situation discussed below,
and for general administrative and node access to the server.

If there isn't an outstanding request, I'll probably go ahead and
ask that one be made.

 -- Tom

Thomas A. La Porte, DreamWorks SKG
<mailto:tlaporte AT anim.dreamworks DOT com>

On Tue, 27 May 2003, Richard Sims wrote:

>>Is it just me or does everyone think that placing
>>sensitive userids and passwords in clear text is just
>>a bad thing?
>
>It's bad.
>
>>Not complaining about the procedure here, you gotta do
>>what you gotta do, but has anyone complained to IBM
>>about requiring clear text passwords for this and
>>other scripts?
>
>There is no requirement for passwords to be in scripts - that was
>just someone's conventional implementation of a convenience script.
>Discretionary halts of the TSM server - as is the case with any daemon
>style application - are best done via its conventional adminstrative
>means: in TSM that is disabling sessions thereafter doing a Halt.
>(Try to avoid thinking that everything running in a Unix environment
>should be controllable via some rc script.)
>
>During a TSM install, that process plants a server start-up method
>appropriate to the environment, such as /etc/inittab in AIX.
>One can emulate whatever that is in a "superuser" invocation to
>start the TSM server.  In traditional Unix, halting the TSM server
>can be achieved automatically during Unix shutdown via /etc/rc.shutdown ,
>wherein that root-accesssible-only script would contain a dsmadmc command
>with passsword.  It is also conventional in Unix implementations of the
>TSM server that the server shuts itself down cleanly when it receives a
>SIGTERM signal (the default signal issued by the Unix 'kill' command).
>
>In thinking about sensitive information related to servers in general,
>consider that, pretty much by definition, a server should be physically
>secure and not be a system used by ordinary users.  Files containing
>sensitive information should have directory and file permissions which
>restrict access by those needing it.  And where passwords need apply,
>various means can be employed to avoid having to code them into files
>(sudo, proxy, etc.).
>
>  Richard Sims, BU
>
>