The command line then shows up in a process listing using the ps command. He informs the culprit and advises them of the dangers of this and tells them to rectify the issue by using:
and then supplying the username/password@sid in the SQL script being used. It had come to his attention that users of the sqlldr binary were also leaking the password by supplying it on the command line. He was stumped as to how to fix this. I supplied the answer which I thought I would share tonight with others so that they can also stop this issue.
The simple answer is to use a parfile. This is a file that contains the SQL*Loader commands and could look like this:
$ cat parfile.par
This is then invoked as follows:
$ sqlldr parfile=parfile.par
This will prevent the leakage of the password into the process list but will present a new problem. The password is then stored in a script. This is a perennial issue. The answer is really down to levels of risk. The parfile can be protected at the file system level to prevent it being read. Ideally do not make it accessible to the owner of the oracle software or the dba group as this will prevent access from many of the functions such as UTL_FILE that allow operating system files to be read or written from within the database. Also the file could be generated or hand written just before use and then destroyed immediately after use. There are many other ideas that could be explored, as I said it really comes down to levels of risk. The particular issue here was how to prevent the process list leakage. Unfortunately this sort of problem often creates a new one.
Finally although not discussed with my colleague the same issues apply with other Oracle tools such as exp and imp and can be solved in the same way.