DSXchange

Dear All. I have one sequential job which need to invoke a ksh.Connect to database is required in the script, and we currently use command "db2 connect to db_name user user_id using pswd" to achieve it.

But Unix command ps -ef will display the full information of this command as running. So db connection info is exposed..

Can anyone know how to fix this issue?

Thanks in advance for any reply.

How would you 'fix' this if you were doing this outside of DataStage? Do you have any alternate way to supply the password from the command line?

First, Our password can't be displayed in the DS director,that means we canot pass the password value through the ds sequential stage command line.So we created one ds job to write the passwords into a encrypted file, and scripts will read the passwords from it.

However,for now,this method can only avoid password exposed in the ds director but can be captured by Unix command ps -ef.

First, Our password can't be displayed in the DS director,that means we canot pass the password value through the ds sequential stage command line.So we created one ds job to write the passwords into a encrypted file, and scripts will read the passwords from it.

However,for now,this method can only avoid password exposed in the ds director but can be captured by Unix command ps -ef.

So, why not just create a job using the DB2 stage, with an encrypted password parameter, to connect to your DB2 database and does whatever the script is trying to accomplish on the database.

lstsaur wrote:So, why not just create a job using the DB2 stage, with an encrypted password parameter, to connect to your DB2 database and does whatever the script is trying to accomplish on the database.

ps -ef will still display this as it is being passed to the job. That is, until parameters are shifted by dsjob. However, IBM released a fix for dsjob so that a file containing parameters can be read by dsjob instead passed on the command line. As far as your unix command, why not pass your credentials via standard input so that they don't show up on the command line? If you want to write to file containing the credentials using the sequential file stage, you should still pass it as a string via standard input and not via the command line.

From what I understand, this user is required to run a KSH script.

This KSH script does a variety of things including a DB2 connection.

The user want to know how to prevent the DB2 call from exposing the password.

The solution is to shift the connection script into the DB2 command file (db2 -f[filename]). In this file, just add "connect to [database] [user] using [password]". Make sure to restrict the file access to the specific user in question with no group rights, and make sure to delete the file afterward.

Teej wrote:From what I understand, this user is required to run a KSH script.

This KSH script does a variety of things including a DB2 connection.

The user want to know how to prevent the DB2 call from exposing the password.

The solution is to shift the connection script into the DB2 command file (db2 -f[filename]). In this file, just add "connect to [database] [user] using [password]". Make sure to restrict the file access to the specific user in question with no group rights, and make sure to delete the file afterward.

That solution if implemented wrong will still lead to the password being exposed. For instance, if the passwords are stored somewhere and he must build the file, he must do so carefully. Let's say hypothetically they are stored in datastage as encrypted params. If he uses the sequential file stage to build this file and he uses the echo unix command and not the ksh print command, the echo command will display the passwords using ps -ef.

No, I have checked that ps -ef will NOT see the job's password.

lstsaur wrote:No, I have checked that ps -ef will NOT see the job's password.

Yeah, I think you're right. I am remembering that for some of the stages the passwords are exposed at the command line in datastage by doing a ps -ef | grep echo because it passes the passwords to
"/usr/bin/ksh -c<variable>" and the variable is the command echo with the decrypted password.

Dear all. Many thanks for your reply.

Let me explain some of your questions.

1.Why I didn't create DS jobs to achieve the same logic which were done by scripts?Answer:As you may know,some complicated operations can't be done by ds jobs.For instance,How to delete parital data from 2 billion ?How to achieve runstats on tables ?How to merge data from a table into another table?

2.Like Teej noted,run some KSH is required,And I think his solution can work for me.And for Ultramundane's concern won't occurs.Since our generate password ds job won't pass the password value via command line.

3.Why I didn't pass our password values via standard input?Answer:Since our project includes not only one or two jobs,it contains hunderds of ds jobs,We have a automation system will control them running.So pass the password manually is impossible.