Datastage command line

[ogmios]

What we did is that the scheduler account is secure with only 2 people having access, the passwords are stored in a file which is chmod 700. This file is sourced in (unencrypted passwords) and in the past the variables were used to pass to dsjob.

But then you could see the password in "ps -ef", so now we write the encrypted password and other params to a temp file and start dsjob with that.
The only people who have ever access to the file with unencrypted passwords are the 2 people with access to the scheduler account (and the system administration people of course :D )

We thought of encrypting passwords but then we hit upon the DataStage password security problem and we never encrypted the passwords ourselves, whatever encryption you would use yourself has the same weakness as the DataStage encryption. It has to work both ways decrypt/encrypt to be able to pass in the password properly.

Regards,
Ogmios

[gateleys]

so now we write the encrypted password and other params to a temp file and start dsjob with that.

ogmios, the above statement says that you are using encrypted password in the dsjob command.

My contention is that an encrypted password should fail the credential check test.

For example if the password is mypass, then when the plaintext password is passed as below, it will work... of course.

Code: Select all

dsjob -server MYSERVER -user gateleys -password mypass -run MYPROJ testjob

However, from your statement it seems you are implying that you pass encrypted password (suppose, encrypted version of mypass is XADYZCDF#RF), as below then it works -

Code: Select all

dsjob -server MYSERVER -user gateleys -password XADYZCDF#RF -run MYPROJ testjob

Now of course, you are using -file to get the param and value from file, but would be equivalent to the logon clause of dsjob, as shown above.

The second command just doesn't make sense to me.

[ogmios]

my mistake... the passwords are not encrypted.

They are all unencrypted in a file which can only be accessed by 2 people because of OS permissions. They are also unencrypted written to a small temp file which is then used by dsjob so that the password doesn't appear on the command line (via ps -ef)

In our case 2 people can access the file and they can see the unencrypted passwords yes. The whole idea is that whatever encryption you use (you could e.g. make your own encryption, and decrypt again in the script calling dsjob) with enough examples and time they can be reverted as encryption/decryption needs to work both ways.
Unix passwords e.g. don't suffer that problem as they are never decrypted.