如果您查看权限：

$ 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