RE: ** UNIX : set echo on in shell

Jared makes an excellent point. And if you're on an older release the *UX OS
family nicely published passwords in ps.

 

Here are a couple example setups to avoid this sort of problem:

 

cat runksh1.ksh

#! /bin/ksh

#  Copyright (C) 1994  Rightsizing, Inc.

#

#  Used by permission, All Rights Reserved

#

#  runksh1 -- Run a sqlplus script as user/pw

#             file without showing the password in ps.

#

#  Usage:    echo "user/pw" | ksh runksh1 scriptname [parameters]

read userpw

scriptname=$1

shift 1

parameters=$@

sqlplus << INPUT01

$userpw

start $scriptname $parameters

exit

INPUT01

 

and for background:

 

#! /bin/ksh

#  Copyright (C) 1994  Rightsizing, Inc.

#

#  Used by permission, All Rights Reserved

#

#  runksh -- Run a sqlplus script as system in background

#            to a timestamped output file without showing

#            the password in ps.

#

#  Usage:    echo "password" | ksh runksh scriptname outputroot [parameters]

read password

datestring=`date +%Y%m%d`

scriptname=$1

outputroot=$2

shift 2

parameters=$@

sqlplus 1>$outputroot.$datestring 2>&1 << INPUT01 &

system/$password

start $scriptname $parameters

exit

INPUT01

 

Now these two wrappers run sqlplus with a script and parameters and catch
pretty much everything so it works with background and nohup. Of course if
you want to run it from cron you'll need to supply what you're going to echo
in, so your cron commands will have to be secure.

 

I have found this style to be useful and functional for 2009-1994 years. (I
guess that is fifteen).

 

I'm not sure, but there might be things you can do with Jared's style of
doing this that you can't do with mine. Still, you'll probably find uses for
both.

 

Good luck,

 

mwf

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jared Still
Sent: Wednesday, March 04, 2009 6:18 PM
To: william@xxxxxxxxxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: ** UNIX : set echo on in shell

 

On Wed, Mar 4, 2009 at 2:36 PM, William Robertson
<william@xxxxxxxxxxxxxxxxxxxx> wrote:

How about:

exec > mylogfile.log 2>&1


Keep in mind that while this type of logging is great for debugging,
it can be a problem for general logging purposes.

Everything gets written to the logfile, which may not be what you want.

"Everything" could include passwords.

Here's one example:

$RMAN_CMD  <<-EOF | $GREP -ivE 'connect target|connect catalog' | tee
$LOGFILE
set echo on;
connect target $DB_USER/$DB_PASSWORD@$DATABASE;
connect catalog $RCAT_USER/$RMAN_PASSWORD@$RMAN_CATALOG;
show all;
RUN
{
        set until time "to_date('$TARGET_DATE','mm/dd/yyyy hh24:mi')";
        restore database validate;
        restore validate archivelog from time
"to_date('$ARCH_BEGIN_DATE','mm/dd/yyyy hh24:mi')"
                until time "to_date('$TARGET_DATE','mm/dd/yyyy hh24:mi')";
}
EOF

The grep is used to strip out the CONNECT commands in the log output.

In 10g this will appear as "connect *" in the output.

In anything older than 10g, it appears as "connect username/password@db" 
which is probably not something you want in a logfile.


Jared

 

Other related posts: