1.4 使用 umask
背景 正如所知,您可以使用 chmod 命令更改 *nix 中的权限。 但是,由于 chmod 仅在现有文件上工作,您如何确保以后创建的文件具有相同的权限?
为了说明这一点,假设您希望目录中的所有文件都具有权限 r--r--r--(或 444)。 通过发出以下命令很容易做到这一点: $ chmod 444 *
现在在目录上创建一个没有内容的简单文件,查看它的权限。 $ touch a_file.txt
$ ls -l a_file.txt
-rw-r--r-- 1 orasoft dba 0 Oct 21 13:44 a_file.txt
对于所有者,权限设置为读写,对于组设置为读,对于其他用户设置为读(或者 644),而不是您预期的 444。为什么?
在新创建的文件上设置的确切权限由一个名为 umask 的特殊参数指定。 umask 是一个值集,从所有权限中减去该值集可以得到新文件的权限值。 例如,如果将 umask 设置为 777,从整体权限值 777 中减去该值,得到 000,即新文件没有任何权限。让我们来看一个示例: $ umask 777
$ touch b_file.txt
$ ls -l ?_file.txt
-rw-r--r-- 1 oracrmp dba 0 Oct 21 13:44 a_file.txt
---------- 1 oracrmp dba 0 Oct 21 13:53 b_file.txt
请注意,文件 b_file.txt 的权限为 000 或 ---------。 此外,请注意,先前创建的文件 a_file.txt 仍然被设置为原来的权限。 将 umask 设置为 777 得到新文件的权限。
umask 是为 Oracle 将创建的不同文件设置权限的强大有效的方法。
策略 Oracle 软件所有者的整体 umask 为 022,因此文件所有者的权限为读写,所有其他用户的权限为读。 您可以将该内容放到用户的登录配置文件中,以便它随时生效。
Oracle 使用的文件有很多不同类型,数据文件、重做日志文件、跟踪文件等等。 数据文件可以预先知道,您可以轻松更改它们的权限,但是跟踪文件是在运行时生成的。 因此,您应该使用 umask 来确保这些跟踪文件没有暴露给任何外部用户,因为这些文件包含可能被黑客利用的各种机密信息。 例如,理论上,某人可以通过复制跟踪文件来窃取数据文件,并将其安装在单独的服务器上,调出数据库以窃取其内容。
为目录设置 umask,如下所示:
目录 |
说明 |
umask |
初始化参数 background_dump_dest 指定的目录 |
某些跟踪文件和数据库警报文件都在此处生成。 权限应为 rw-------(仅 Oracle 软件所有者具有读写权限)。 |
0177 |
初始化参数 user_dump_dest 指定的目录 |
跟踪文件在此处生成。 权限应与上面相同。 |
0177 |
$ORACLE_HOME/rdbms/log |
某些数据库日志文件在此处生成。 权限应与上面相同。 |
0177 |
$ORACLE_HOME/rdbms/audit |
默认情况下,数据库审计的审计跟踪存储在此处,除非您已经设置了 audit_file_dest 初始化参数。 权限应与上面相同。 即使您有 DB 审计跟踪,某些通用事件(例如 SYSDBA 连接和数据库启动/关闭)始终在此处审计和放置。 |
0177 |
初始化参数 audit_file_dest 指定的目录 |
默认情况下,数据库审计的审计跟踪存储在此处,除非您已经设置了 audit_file_dest 初始化参数。 权限应与上面相同。 |
0177 |
结论 以这种方式设置 umask 可以防止某些开发人员访问会话跟踪文件,这些文件在 user_dump_dest 目录中生成并被传递到 tkprof 进行格式化。 因此,您可能希望仅在该目录上放松规则。 操作计划
- 将 background_dump_dest 上的 umask 更改为 0177。
- 将 $ORACLE_HOME/rdbms/log 上的 umask 更改为 0177。
- 将 $ORACLE_HOME/rdbms/audit 上的 umask 更改为 0177。
- 将 audit_file_dest 上的 umask 更改为 0177。
- (可选)将 user_dump_dest 上的 umask 更改为 0177。
1.5 限制 SYSDBA 登录
背景 您可能已经注意到,属于组“dba”成员的任何 *nix 用户都可通过以下命令以 SYSDBA 用户身份登录: sqlplus / as sysdba
这通常被认为是一件很方便的事,因为您不需要记住或输入用户 SYS 的密码。 但是,这也带来了一个漏洞: 任何可通过 dba 组成员身份登录的用户都可通过 SYS 身份登录数据库。 导致 SYS 的加强密码并不经常使用。 如果您有一个牢固的 SYS 帐户,您可能应该对其以及 dba 组用户进行保护,使得以 SYS 身份登录必须提供 SYS 密码。 这种方法不会消除渗透的风险,但是可以使该风险显著降低。
策略 该进程由文件 SQLNET.ORA 中的参数 SQLNET.AUTHENTICATION_SERVICES 控制。如果将该参数设置为 NONE,会禁用 SYSDBA 角色的自动登录。 要禁用 SYSDBA 角色的自动登录,可将以下行放到位于 $ORACLE_HOME/network/admin 目录中的 SQLNET.ORA 文件中。 SQLNET.AUTHENTICATION_SERVICES=(NONE)
从此时起,如果属于组 dba 的 *nix 用户希望使用类似的登录连接: $ sqlplus / as sysdba
他们将收到: ERROR:
ORA-01031:insufficient privileges
要进行连接,必须提供 SYS 密码: $ sqlplus /nolog
SQL> connect sys/oracle as sysdba
这可以防止仍然不知道 SYS 密码的人访问 dba 帐户。
结论 如上所示,最重要的是使用 SYS 密码。 您可能需要对连接至 SYS 的脚本做一些改动。
如果您曾经丢失过 SYS 密码,不要担心。 您可以对文件 SQLNET.ORA 中的行进行注释,然后按照传统方式进行连接,即 / as sysdba。 操作计划
IF 您在脚本中使用 SYS 连接 THEN |
|
将 / as sysdba 更改为 sys/<SysPassword> as sysdba 将 SQLNET.AUTHENTICATION_SERVICES=(NONE) 置于文件 SQLNET.ORA 中 |
ELSE |
|
无需任何更改 |
END IF | (编辑:aniston)
|