例如，在我审计过的许多安装中，STATSPACK 作为 shell 脚本运行，如下所示：

export ORACLE_HOME=/u01/app/oracle/10.1/db
export ORACLE_SID=MYSID
cd $ORACLE_HOME/bin
$ORACLE_HOME/bin/sqlplus -s perfstat/perfstat @statspack.sql

然后，通过 cron 或 Windows 计划程序计划此 shell 脚本。该方法存在两个主要风险：

• 入侵者可能会找到文件 statspack.sh 并看到用户 perfstat 的口令。
• 当 shell 脚本正在运行时，*nix 服务器上的某人可以执行 ps -aef 命令，并在查看该命令运行的同时清楚地看到口令。

当我询问使用该方法的原因时，得到的答案几乎完全相同：因为以前的 DBA 就是如法炮制的。无论原因如何，威胁都是显而易见的，并且必须予以清除。

sqlplus -s scott/$SCOTTPASSWORD @script.sql

其中的 SCOTTPASSWORD 是在执行该脚本前定义的一个环境变量。当用户执行 /usr/ucb/ps uxgaeww 命令时，他可以看到将曝露口令的过程中使用的所有环境变量。因此，必须通过某种方法有效地隐藏口令。下面将对这些方法加以介绍。

方法 1.一种简单的方法是在 SQL*Plus 中使用 nolog 参数。在此方法中，前面的脚本应改为

export ORACLE_HOME=/u01/app/oracle/10.1/db
export ORACLE_SID=MYSID
cd $ORACLE_HOME/bin
$ORACLE_HOME/bin/sqlplus /nolog @statspack.sql

使用此脚本可以建立一个 SQL*Plus 会话，但该会话尚未连接到数据库。在 statspack.sql 脚本内部，应设置用户 ID 和口令：

connect perfstat/perfstat
... the rest of the script comes here ... 

这样一来，当某人执行 ps -aef 命令时，他将看不到用户 ID 和口令。（顺便提一下，对于以交互方式启动 SQL*Plus 会话而言，这也是一个最佳实践。）

方法 2.以上方法的这一小小变化形式在以下场合下很有用：SQL 语句不在 SQL 脚本中，而是直接嵌套入到 shell 脚本中，例如：

$ORACLE_HOME/bin/sqlplus user/pass << EOF
... SQL statements come here ... 
EOF

可以将此 shell 脚本改为

$ORACLE_HOME/bin/sqlplus /nolog << EOF
connect user/pass
... SQL statements come here ... 
EOF

该方法对于构建快捷而质量不高的 shell 脚本（用来处理 SQL）而言也是一个最佳实践。

方法 3.在该方法中，您可以创建一个包含用户 ID 和口令的口令文件，并可以在运行时间读取它们。首先，创建一个名为 .passwords 并包含所有用户 ID 和口令的文件（注意文件名前面的句点）。由于该文件名以句点开头，因此某人在使用 ls -l 命令时将看不到该文件名（但在使用 ls -la 命令时可以看到该文件名)。然后，将权限更改为 0600，以便只有拥有者能够读取它。

该文件应包含由空格分隔的用户 ID 和口令（每行一个）。

scott tiger
jane tarzan
... 等等... 

现在使用以下代码行创建另一个文件，即一个名为 .getpass.sh 的 shell 脚本（注意句点）。

fgrep $1 $HOME/.passwords | cut -d " " -f2

将此脚本的权限设置为 0700，以便任何其他人都无法看到以及执行该脚本。随后，当需要以 scott 的身份运行脚本时，您只需按如下所示对这些行进行编码即可：

.getpass.sh scott | sqlplus -s scott @script.sql

这将从文件中获得 scott 的口令并将其传递给 sqlplus 命令。如果有人执行 ps 命令，他将看不到该口令。

作为一个额外的好处，您现在已经实现了一个灵活的口令管理机制。每当 scott 的口令更改（作为一个良好的习惯，它应当定期更改）时，您只需编辑口令文件即可。

(编辑:aniston)