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
Datastage command line
Moderators: chulett, rschirm, roy
ogmios, the above statement says that you are using encrypted password in the dsjob command.ogmios wrote: so now we write the encrypted password and other params to a temp file and start dsjob with that.
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
Code: Select all
dsjob -server MYSERVER -user gateleys -password XADYZCDF#RF -run MYPROJ testjob
The second command just doesn't make sense to me.
gateleys
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.
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.
In theory there's no difference between theory and practice. In practice there is.