Shell Programming and Scripting

Hi there,

This is my first post, so as you have probably guessed I am looking for some help.

Currently we have close to 1000 ksh scripts operating on HPUX servers that call either isql or bcp to connect to Sybase databases. Problem being that the db passwords are appearing in the job log of the scheduler which calls these scripts. I have been asked to come up with a solution to modify these scripts to stop them outputting these passwords.

The version of isql we are using is
Sybase CTISQL Utility/12.5.1/P-EBF13182 ESD #12/DRV.12.5.1.4/hpux/HP-UX 11.11/BUILD1251-045/64bit/OPT/Thu Jan 12 20:44:52 2006


These scripts have been written by a plethora of different developers over the last 10-12 years, and the have set -o xtrace set at the beginning of the scripts to provide debugging information should one of these scripts fail. I have included a simple example of a typical script below, database user names and passwords are all stored as environmental parameters in env_params.ksh

Code:

#/usr/bin/ksh
. ./env_params.ksh
set -o xtrace
isql -S DBSERVER -D $DBNAME -U $DBUSER -P $DBPASSWORD <<-EOF
select * from Table
go
EOF

I know that having xtrace set is causing this to happen, but my remit requires that the same level of debugging information should be available after I make my change.

After trawling the web I cam across this possible solution, moving the password from the isql command

Code:

 
#/usr/bin/ksh
. ./env_params.ksh
set -o xtrace

...
...
...

isql -S DBSERVER -D $DBNAME -U $DBUSER <<-EOF
$DBPASSWORD
select * from Table
go
EOF

This works from an isql standpoint but it still outputs the password, as the $DBPASSWORD still has to be evaluated. If I hardcode the actual password in the script (obviously not an option) the password doesn't appear in the script output. The next solution I have come up with is the following which turns off xtrace while the isql command is being run, and setting it back on once the commands has completed.

Code:

#/usr/bin/ksh
. ./env_params.ksh
set -o xtrace

...
...
...

set +o xtrace
echo isql -S DBSERVER -D $DBNAME -U $DBUSER
isql -S DBSERVER -D $DBNAME -U $DBUSER <<-EOF
$DBPASSWORD 
select * from Table
go
EOF
set -o xtrace

However it is a bit messy, and when you consider it has to be applied to nearly 1000 scripts, I am hoping that there maybe a simpler solution out there.

Thanks,
kdk

You could write an isql wrapper also named isql, up-PATH, that knows the path of the real isql, and knows how to acquire the password and add it to the input stream.

It might also remove any -P parameters and re-exec (which isql should have been doing).

Thanks for the feedback DGPickett, I am not sure whether our Unix Admins would go for your suggestion.By any chance does anyone know if this problem would be resolved if we upgraded our version of isql to 15.0.2?

Any user can run any app with a modified PATH to pick up a modified command. It is not generally a security violation. SA's do it all the time, adding wrappers to commands. My ssh is a shell script calling ssh2! Here is a little ksh example:

Code:

(
export real_isql=$( which isql )
PATH=~/my_isql_dir:$PATH
run your apps that need isql passwords
)

The parentheses keep that PATH from spreading to other commands. File ~/my_isql_dir/isql is your isql wrapper, and knows the real isql is $real_isql.

Of course, with the support of the gods, you can move the original isql over to isql_real and put your script right there. You just need some way to decide when to add the password, like a reserved argument, perhaps '-P hidden_password', and otherwise just call isql_real. I doubt isql looks at argv[0] to ensure it is "isql", like gzip does (it is all one code for gzip, gunzip, gzcat).

Interestingly, you cannot do this stdin pretend interactive trick with ssh2, as it reads /dev/tty! (But there are stronger tricks!)