 | |
SQL Loader and password on the command line.
comp.databases.oracle.misc comp.databases.oracle.misc
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
SQL Loader and password on the command line. -
10-29-2007
, 09:54 AM
|
mknod a.par p echo user/pass>a.par & [1] 17097 sqlldr parfile=a.par control=a Username: |
SQL*Loader: Release 9.2.0.4.0 - Production on Mon Oct 29 11:47:53 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL*Loader-128: unable to begin a session
ORA-01017: invalid username/password; logon denied
[1]+ Done echo user/pass >a.par
When prompted for a username i hit CTL-C and ENTER.
There does not seem to be any environment variable for username or
password, and putting it in TWO_TASK does not help.
Is there a way to pass a password to SQL Loader without having it
exposed on the command line or unencrypted on disk?
B.
#2
| |||
| |||
|
|
We seem to have bumped into a common issue, and that is that we need to automate the loading of a few thousand files nightly. EXTERNAL TABLEs seem not to be the answer, as the files are on other servers. Both copying the files to the DB server and using an NFS mount are not allowed by policy. So, we are to use sqlldr. However, sqlldr expects a username/password. Passing it on the command line is viewable via ps, which leaves the PARFILE option, but that has it written to disk while unencrypted. Creating a named pipe does not seem to help for the PARFILE: mknod a.par p echo user/pass>a.par & [1] 17097 sqlldr parfile=a.par control=a Username: SQL*Loader: Release 9.2.0.4.0 - Production on Mon Oct 29 11:47:53 2007 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. SQL*Loader-128: unable to begin a session ORA-01017: invalid username/password; logon denied [1]+ Done echo user/pass >a.par When prompted for a username i hit CTL-C and ENTER. There does not seem to be any environment variable for username or password, and putting it in TWO_TASK does not help. Is there a way to pass a password to SQL Loader without having it exposed on the command line or unencrypted on disk? B. |
HTH
-g
#3
| |||
| |||
|
|
We seem to have bumped into a common issue, and that is that we need to automate the loading of a few thousand files nightly. EXTERNAL TABLEs seem not to be the answer, as the files are on other servers. Both copying the files to the DB server and using an NFS mount are not allowed by policy. So, we are to use sqlldr. However, sqlldr expects a username/password. Passing it on the command line is viewable via ps, which leaves the PARFILE option, but that has it written to disk while unencrypted. Creating a named pipe does not seem to help for the PARFILE: mknod a.par p echo user/pass>a.par & [1] 17097 sqlldr parfile=a.par control=a Username: SQL*Loader: Release 9.2.0.4.0 - Production on Mon Oct 29 11:47:53 2007 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. SQL*Loader-128: unable to begin a session ORA-01017: invalid username/password; logon denied [1]+ Done echo user/pass >a.par When prompted for a username i hit CTL-C and ENTER. There does not seem to be any environment variable for username or password, and putting it in TWO_TASK does not help. Is there a way to pass a password to SQL Loader without having it exposed on the command line or unencrypted on disk? B. |
sqlldr CONTROL=${DATA}/ctl_file.ctl DATA=$DATA/$INFILE LOG=$LOGS/
$LOGFILE <<_STOP_
$USERID
_STOP_
#4
| |||
| |||
|
|
On Oct 29, 11:54 am, Brian Tkatch <N/A> wrote: We seem to have bumped into a common issue, and that is that we need to automate the loading of a few thousand files nightly. EXTERNAL TABLEs seem not to be the answer, as the files are on other servers. Both copying the files to the DB server and using an NFS mount are not allowed by policy. So, we are to use sqlldr. However, sqlldr expects a username/password. Passing it on the command line is viewable via ps, which leaves the PARFILE option, but that has it written to disk while unencrypted. Creating a named pipe does not seem to help for the PARFILE: mknod a.par p echo user/pass>a.par & [1] 17097 sqlldr parfile=a.par control=a Username: SQL*Loader: Release 9.2.0.4.0 - Production on Mon Oct 29 11:47:53 2007 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. SQL*Loader-128: unable to begin a session ORA-01017: invalid username/password; logon denied [1]+ Done echo user/pass >a.par When prompted for a username i hit CTL-C and ENTER. There does not seem to be any environment variable for username or password, and putting it in TWO_TASK does not help. Is there a way to pass a password to SQL Loader without having it exposed on the command line or unencrypted on disk? B. Here's how to do if from a korn shell script sqlldr CONTROL=${DATA}/ctl_file.ctl DATA=$DATA/$INFILE LOG=$LOGS/ $LOGFILE <<_STOP_ $USERID _STOP_ |
disk definitely works.
Thanx!
That should secure it from everyone but root.
B.
#5
| |||
| |||
|
|
On 29 Oct, 15:54, Brian Tkatch <N/A> wrote: We seem to have bumped into a common issue, and that is that we need to automate the loading of a few thousand files nightly. EXTERNAL TABLEs seem not to be the answer, as the files are on other servers. Both copying the files to the DB server and using an NFS mount are not allowed by policy. So, we are to use sqlldr. However, sqlldr expects a username/password. Passing it on the command line is viewable via ps, which leaves the PARFILE option, but that has it written to disk while unencrypted. Creating a named pipe does not seem to help for the PARFILE: mknod a.par p echo user/pass>a.par & [1] 17097 sqlldr parfile=a.par control=a Username: SQL*Loader: Release 9.2.0.4.0 - Production on Mon Oct 29 11:47:53 2007 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. SQL*Loader-128: unable to begin a session ORA-01017: invalid username/password; logon denied [1]+ Done echo user/pass >a.par When prompted for a username i hit CTL-C and ENTER. There does not seem to be any environment variable for username or password, and putting it in TWO_TASK does not help. Is there a way to pass a password to SQL Loader without having it exposed on the command line or unencrypted on disk? B. I would consider creating an "IDENTIFIED EXTERNALLY" OPS$ account. HTH -g |
B.
#6
| |||
| |||
|
|
Interesting idea, but we'd never get them to allow that here. B. |
Why not? It's as secure as you're operating system. It's not like
you're in a Windows platform or anything
#7
| |||
| |||
|
|
On 29 Oct, 17:46, Brian Tkatch <N/A> wrote: Interesting idea, but we'd never get them to allow that here. B. Why not? It's as secure as you're operating system. It's not like you're in a Windows platform or anything |
strict as well.
B.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.