背景
看看 $ORACLE_HOME/bin 目录中的其他可执行文件；有些看起来很熟悉，例如 sqlplus 或 lsnrctl（启动监听程序的实用工具）；有些您可能并不熟悉。

其中一些文件（例如监听程序进程运行的实用工具 tnslsnr 或在 Oracle Intelligent Agent 中使用的 dbsnmp）最终用户不会直接接触到。 要正确保护这些文件，您必须了解它们的作用，从而采取相应的措施。

请记住，如果为文件设置了 SUID 位，则无论哪个用户运行该文件，该文件都在所有者的权限下运行，而不是在执行者的权限下运行。 您还应清楚，设置 SUID 是一种危险行为，不应给予鼓励。

还有一些文件将 SUID 设置为 on。 让我们将它们找出来。

$ cd $ORACLE_HOME
$ find . -type f \( -perm -2000 -o -perm -4000 \) -exec ls -l {} \; 

在 Oracle 数据库 10g 第 1 版和更高版本中，上述命令应仅返回以下可执行文件：

-rwsr-s--x    1 orasoft  dba      93300507 Jul 22 11:20 ./bin/oracleO
-r-sr-s---    1 root     dba             0 Jul  1 23:15 ./bin/oradism
-rwsr-s--x    1 orasoft  dba         94492 Jul 22 11:22 ./bin/emtgtctl2
-rwsr-s---    1 root     dba         18944 Jul 22 11:22 ./bin/nmb
-rwsr-s---    1 root     dba         20110 Jul 22 11:22 ./bin/nmo
-r-sr-sr-x    1 nobody   nobody      58302 Jul 22 11:23 ./bin/extjob

我们来看看这些文件是哪些：

在 Oracle9i 数据库第 2 版中，您将发现另一个文件 ./bin/dbsnmp，它是 Oracle Intelligent Agent 可执行文件。 权限的设置如下：

-rwsr-s--- 1 root dba 2986836 Jan 26 2005 dbsnmp

该文件的问题是它需要 root 权限才能正常工作，因此必须将 SUID 位设置为 on。 但是，由于该文件的所有者是 root，因此黑客通常利用它以 root 身份获得访问。 最好的方法是消除它，或者将其所有者改为 Oracle 软件所有者，将权限设置为 700。您将失去一些功能，但是为了消除风险，这是值得的。

另一个要考虑的可执行文件是 tnslsnr，它是 Oracle 网络监听程序。 有两个可执行文件：

tnslsnr - 实际的监听程序可执行文件
lsnrctl - 用于管理监听程序（例如启动、停止等）的实用工具。

如果您查看权限：

$ ls -l *lsnr*
-rwxr-x--x   1 orasoft    oinstall    214720 Oct 25 01:23 lsnrctl
-rwxr-xr-x   1 orasoft    oinstall    214720 Oct  1 18:50 lsnrctl0
-rwxr-x--x   1 orasoft    oinstall   1118816 Oct 25 01:23 tnslsnr
-rwxr-xr-x   1 orasoft    oinstall   1118816 Oct  1 18:50 tnslsnr0

这些文件全都具有执行权限。 与可执行文件 oracleO 一样，通过重新链接 Oracle 软件创建新文件 tnslsnr 时，已有的文件被重命名为 tnslsnr0。 这样做是因为，如果需要回退该进程，可以将旧的可执行文件复制到新的可执行文件上。 因为是旧的可执行文件的副本，因此文件 tnslsnr0 可能包含原来的 tnslsnr 的功能。 lsnrctl0 也是一样。

策略
既然您了解了每个可执行文件的作用，让我们来看看您如何能够保护数据库基础架构。 大部分策略已经在前面部分的背景信息中进行了讨论。 因此，实际上，您的策略措施是：

1. 删除不需要的文件（例如 lsnrctl0）的所有权限。
2. 限制仅 Oracle 软件具有可执行文件的权限。
3. 如果 Oracle 软件所有者启动进程，删除 SUID 位。

因此，您希望更改与监听程序相关的文件的权限，如下所示：

$ chmod 700 lsnrctl tnslsnr
$ chmod 000 lsnrctl0

验证结果。

$ ls -l *lsnr*
-rwx------   1 orasoft    oinstall    214720 Oct 25 01:23 lsnrctl
----------   1 orasoft    oinstall    214720 Oct  1 18:50 lsnrctl0
-rwx------   1 orasoft    oinstall   1118816 Oct 25 01:23 tnslsnr
----------   1 orasoft    oinstall   1118816 Oct  1 18:50 tnslsnr0

结论
从本例可得出以下几个结论：

• 更改 oracleO 可执行文件对数据库的操作没有影响。 如果曾经遇到导致“oracle”可执行文件损坏的问题，最好的做法是将“oracleO”文件重命名为“oracle”。 若如此，请确保将权限重设为 700。对 lsnrctl0 和 tnslsnrctl0 文件也是如此。

• 如果使用 Oracle 软件所有者用户 ID 作为企业管理器操作系统凭证，更改 emtgtctl2 权限将没有任何影响。 如果使用其他用户 ID（例如，不是 orasoft），则必须将 SUID 重设为原来的值，权限必须设为与原来一样。

• 可执行文件 dbnsmp 由 Oracle Enterprise Manager Intelligent Agent 使用，但是仅延续到 Oracle9i 数据库第 2 版。此外，如果您使用 Oracle 软件所有者作为操作系统凭证，更改权限没有任何影响。 如果您使用其他用户 ID，则必须将权限重设为原来的值。

1. 将 oracleO、tnslsnr0 和 lsnrctl0 的权限更改为 0000。
2. 将 tnslsnr 和 lsnrctl 的权限更改为 0700。
3. 您在企业管理器中是否使用外部作业？

   IF 没有 THEN 将 extjob 的权限更改为 0000 ELSE
   	将 extjob 的权限更改为 0700 并将所有者和组更改为 orasoft 和 oinstall（或任何 Oracle 软件所有者的用户和组）。
   END IF

4.  

   IF 您运行在 Oracle9i 数据库上 THEN
   	您是否使用 Oracle Intelligent Agent？
   IF 没有 THEN
   	将 dbsnmp 的所有权更改为 orasoft 将权限更改为 0700
   ELSE
   	无需任何更改
   END IF