Skip to content

Oracle security - 3. page

Oracle Database PSU与CPU的区别

最近不少人问我关于CPU以及PSU的区别问题，我把这个问题的解释发到这里来，具体如下：

转载自：http://www.cnblogs.com/ebs-blog/archive/2011/07/28/2167232.html

1. 什么是PSU/CPU？
CPU: Critical Patch Update
Oracle对于其产品每个季度发行一次的安全补丁包，通常是为了修复产品中的安全隐患。

PSU: Patch Set Updates
Oracle对于其产品每个季度发行一次的补丁包，包含了bug的修复。Oracle选取被用户下载数量多的，并且被验证过具有较低风险的补丁放入到每个季度的PSU中。在每个PSU中不但包含Bug的修复而且还包含了最新的CPU。

2. 如何查找最新的PSU？
每个数据库版本都有自己的PSU，PSU版本号体现在数据库版本的最后一位，比如最新的10.2.0.5的PSU是10.2.0.5.3，而11.2.0.2的最新PSU则是11.2.0.2.2。
MOS站点中Oracle Recommended Patches — Oracle Database [ID 756671.1] 文档中查到各个产品版本最新的PSU。
如果你记不住这个文档号，那么在MOS中以“PSU”为关键字搜索，通常这个文档会显示在搜索结果的最前面。

注意：必须购买了Oracle基本服务获取了CSI号以后才有权限登陆MOS站点。

3. 如何正确安装PSU？
每个PSU安装包中都包含一个README.html文档，其中描述了如何安装该PSU，有些PSU是可以直接安装的，而有些PSU则必须要求安装了上一 个版本的PSU之后才能继续安装。比如对于10.2.0.4版本的数据库来说，PSU 10.2.0.4.4可以直接安装在最原始的10.2.0.4.0版本中，而最新的PSU 10.2.0.4.8则必须要求先安装10.2.0.4.4。这些信息在README.html中都可以找到，所以请仔细阅读该文档。

通常安装PSU是比较简单的，步骤如下：
1) 安装PSU需要使用到opatch，在README.html中有描述该PSU需要的最低版本opatch，如果当前opatch版本过低，则需要先下载 Patch 6880880，该Patch中包含最新的opatch，只需要解压覆盖原先的$ORACLE_HOME/OPatch目录即可。

查看当前的opatch版本，可以使用opatch version命令。

$ opatch version

Invoking OPatch 10.2.0.5.2

OPatch Version: 10.2.0.5.2

OPatch succeeded.

2）安装PSU，请仔细阅读README.html，确认安装命令，通常是简单的opatch apply。

$opatch apply

3）更新数据库，将修改过的SQL文件应用到数据库中，很多DBA在执行完上述安装命令以后就不再进行这一步，那么实际上PSU是没有完整安装的。

cd $ORACLE_HOME/rdbms/admin

sqlplus / as sysdba

SQL> STARTUP

SQL> @catbundle.sql psu apply

SQL> QUIT

注意：如果PSU是overlay PSU，比如10.2.0.4.8，则需要执行@catbundle.sql opsu apply，同样这些在README.html中都有详细描述。

4）重新编译CPU相关视图。该步骤在一个数据库上永远只需要执行一次，是为了完成在2008年1月份第一次发布CPU补丁时的后续工作，如果在安 装以前的PSU或者CPU时执行过这个步骤那么就可以无需再次执行，另外，即使不执行该步骤，数据库也是正常运行的，只不过意味着2008年1月份的 CPU补丁没有正常结束安装。

cd $ORACLE_HOME/cpu/view_recompile

sqlplus / as sysdba

SQL> @recompile_precheck_jan2008cpu.sql

SQL> SHUTDOWN IMMEDIATE

SQL> STARTUP UPGRADE

SQL> @view_recompile_jan2008cpu.sql

SQL> SHUTDOWN;

SQL> STARTUP;

SQL> QUIT

注意：该步骤由于需要重新编译大量视图，因此要启动数据库到upgrade状态才可以完成。也就是将引起停机时间。

4. 如何确认当前数据库已经安装了什么PSU/CPU？
无论是从V$VERSION或者DBA_REGISTRY或者PRODUCT_COMPONENT_VERSION视图中，都无法查找到PSU的信息，这些视图中始终显示的是最原始的版本，比如10.2.0.4.0。

最常用的方法是使用opatch命令。在打完最新的PSU 10.2.0.4.8的10.2.0.4数据库中会有以下显示。

$ opatch lsinventory -bugs_fixed | grep -i ‘DATABASE PSU’

9654991 11724977 Wed May 25 16:37:17 CST 2011 DATABASE PSU 10.2.0.4.5 (REQUIRES PRE-REQUISITE

9952234 11724977 Wed May 25 16:37:17 CST 2011 DATABASE PSU 10.2.0.4.6 (REQUIRES PRE-REQUISITE

10248636 11724977 Wed May 25 16:37:17 CST 2011 DATABASE PSU 10.2.0.4.7 (REQUIRES PRE-REQUISITE

11724977 11724977 Wed May 25 16:37:17 CST 2011 DATABASE PSU 10.2.0.4.8 (REQUIRES PRE-REQUISITE

8576156 9352164 Wed May 25 15:10:48 CST 2011 DATABASE PSU 10.2.0.4.1 (INCLUDES CPUJUL2009)

8833280 9352164 Wed May 25 15:10:48 CST 2011 DATABASE PSU 10.2.0.4.2 (INCLUDES CPUOCT2009)

9119284 9352164 Wed May 25 15:10:48 CST 2011 DATABASE PSU 10.2.0.4.3 (INCLUDES CPUJAN2010)

9352164 9352164 Wed May 25 15:10:48 CST 2011 DATABASE PSU 10.2.0.4.4 (INCLUDES CPUAPR2010)

另外的方法是查看registry$history表。

SQL> select action,comments from registry$history;

ACTION                       COMMENTS

——————————-          ——————–

APPLY                          PSU 10.2.0.4.4

APPLY                          PSU 10.2.0.4.8

CPU                               view recompilation

注意：该表的内容是在上述安装PSU步骤的第三步中运行catbundle.sql才会插入的，因此如果该步骤忘记执行，则此表中无记录。因此我们在作数据库健康检查的时候不但要用opatch检查当前数据库最新的PSU补丁，也要检查registry$history表，以确认其它DBA是否正确地完成了PSU的安装。

如果多个PSU的安装都忘记了执行上述第三步，可以通过以下方法依次补作。

$ ls -l $ORACLE_HOME/psu

total 0

drwxrwxrwx 2 oracle dba 96 Oct 16 2010 10.2.0.4.4

drwxrwxrwx 2 oracle dba 96 Oct 16 2010 10.2.0.4.5

$sqlplus / as sysdba

SQL> @?/psu/10.2.0.4.4/catpsu.sql

SQL> @?/psu/10.2.0.4.5/catopsu.sql

更多关于CPU的信息，可以参看：Maclean的了解Oracle Critical Patch Update。

5. 参考文档。
Oracle Recommended Patches — Oracle Database [ID 756671.1]
Patch Set Updates for Oracle Products [ID 854428.1]
Introduction To Oracle Database catbundle.sql [ID 605795.1]
How to confirm that a Critical Patch Update (CPU) has been installed in Linux / UNIX [ID 821263.1]

Oracle Oracle security Oracle 排障配置与调整 | Guang Cai Li |

关于CPU的更新信息。

 

Critical Patch Updates

Critical Patch Updates are collections of security fixes for Oracle products. They are available to customers with valid support contracts. They are released on the Tuesday closest to the 17th day of January, April, July and October. The next four dates are:

  • 14 January 2014
  • 15 April 2014
  • 15 July 2014
  • 14 October 2014

Starting with the October 2013 Critical Patch Update, security fixes for Java SE are released under the normal Critical Patch Update schedule.

A pre-release announcement will be published on the Thursday preceding each Critical Patch Update release.

The Critical Patch Updates released to date are listed in the following table.

Critical Patch Update Latest Version/Date
Critical Patch Update – October 2013
 Rev 1, 15 October 2013
Critical Patch Update – July 2013
 Rev 4, 11 September 2013
Critical Patch Update – April 2013
 Rev 1, 16 April 2013
Critical Patch Update – January 2013 Rev 2, 17 January 2013
Critical Patch Update – October 2012 Rev 1, 16 October 2012
Critical Patch Update – July 2012 Rev 1, 17 July 2012
Critical Patch Update – April 2012 Rev 2, 19 July 2012
Critical Patch Update – January 2012 Rev 3, 23 January 2012
Critical Patch Update – October 2011 Rev 3, 20 October 2011
Critical Patch Update – July 2011 Rev 7, 15 December 2011
Critical Patch Update – April 2011 Rev 5, 12 May 2011
Critical Patch Update – January 2011 Rev 3, 1 February 2011
Critical Patch Update – October 2010 Rev 1, 12 October 2010
Critical Patch Update – July 2010 Rev 1, 13 July 2010
Critical Patch Update – April 2010 Rev 1, 13 April 2010
Critical Patch Update – January 2010 Rev 2, 4 February 2010
Critical Patch Update – October 2009 Rev 1, 20 October 2009
Critical Patch Update – July 2009 Rev 3, 03 September 2009
Critical Patch Update – April 2009 Rev 4, 03 September 2009
Critical Patch Update – January 2009 Rev 4, 03 September 2009
Critical Patch Update – October 2008 Rev 3, 03 September 2009
Critical Patch Update – July 2008 Rev 3, 05 March 2009
Critical Patch Update – April 2008 Rev 4, 22 May 2008
Critical Patch Update – January 2008 Rev 1, 15 January 2008
Critical Patch Update – October 2007 Rev 1, 16 October 2007
Critical Patch Update – July 2007 Rev 2, 19 July 2007
Critical Patch Update – April 2007 Rev 2, 18 April 2007
Critical Patch Update – January 2007 Rev 2, 05 March 2007
Critical Patch Update – October 2006 Rev 4, 06 March 2006
Critical Patch Update – July 2006 Rev 1, 18 July 2006
Critical Patch Update – April 2006 Rev 1, 18 April 2006
Critical Patch Update – January 2006 Rev 1, 17 January 2006
Critical Patch Update – October 2005 Rev 2, 19 December 2005
Critical Patch Update – July 2005 Rev 1, 12 July 2005
Critical Patch Update – April 2005 Rev 2, 13 April 2005
Critical Patch Update – January 2005 Rev 2, 15 March 2005

Note 1571391.1

Oracle security | Guang Cai Li | |   CPU

简便的数据刷选安全控制方式以及不可避免的ORA-01039错误

对于一些使用Oracle或者其他数据库（比如mysql，sql server，sybase，db2等）的企业或者单位，在涉及到一些数据交涉（可能是多级单位之间的数据交换获取）过程中，经常会碰到一些不愿意被对方看到的数据，那么这个时候就需要相关的表数据做刷选再传递给对方，刷选的方式有不少，比如dmg，rls，ols（rls的升级版），fgac，身份验证，role control等，更甚者会用dbv，这些都是oracle在安全方面所做的支持，每一种的设置都有自己优势和弊端，到这里你一定以为我会选择上面的一种方式来实现，哈哈~这里我要介绍的是采用view或者synonym的方式来控制，这里以Oracle数据库中来限制数据访问的最简单的方式为例子，在Oracle中如果相关数据规模不大，或者相关的业务执行频率可控，而且要做dml的限制，那么首先建议就是是采用view或者synonym，反之如果对dml有要求，要么在评估性能的基础上选择上面介绍的方式外，还有物化视图的方式。

具体如下：
我们先提出需求，用户a要求查询b下的b.t1表的关于id=100的数据，但是b用户不希望a用户在能看到t1表下id=100之外的数据，采用view的方式就会如下：

一.测试环境搭建：

create user a identified by ludatoua;
create user b identified by ludatoub;
grant resource,connect to ludatoua;
grant resource,connect to lidatoub;
grant select any dictionary to ludatoua; — 必须要的
grant select any dictionary to ludatoub; — 必须要的
grant select on v_$session to ludatoua;
grant select on v_$sesstat to ludatoua;
grant select on v_$statname to ludatoua;

B用户下：

create table t1 as select * from all_objects; –记得要现有权限
alter table t1 add rn number;
update t1 set rn=300;
update t1 set rn=100 where rownum < 5;

二.根据要求，通过建立view的方式刷选数据：

B用户下：

create view xh$t1 as select * from t1 where id=100;
grant select on ludatoub.xh$t1 to ludatoua;

A用户下操作：
view方式限制：

create synonym t1 for ludatoub.xh$t1;

synonym方式限制：

create synonym t1 for ludatoub.xh$t1;

到了这里我们要做简单的数据刷选（数据访问限制）已经完成了，但是有一个问题是不能被忽略的，ORA – 01039错误（在看执行计划的时候产生导致无法对这个view的执行计划进行观测）， insufficient privileges on underlying objects of the view。错误的解释是相关对象的视图没有权限去访问定义的基表。这样的错误很多人都碰到过，但是都没有一个很好的解决方案，网上公布得最多的是grant select any dictionary to user的方式来解决，但是这个只能解决本身用户的，在我们这的情况下（在ludatoua）用户下，这种方式就起不到左右了。有兴趣的同学可以使用10053或者46去看在看执行计划时候到哪一步报错没权限，我这里就不列出了。
问题的原因在与view的嵌套视图的基础对象，ludatoua用户是没有对ludatoub下的对象select权限的，因为我们需要控制ludatoua不能直接访问ludatoub的t1表。在我们的案例中就是ludatoua用户无法对ludatoub的t1对象进行select才导致了这里看执行计划时候报错 ORA – 01039。这是采用view方式的一种弊端，所以时候时候还是需要权衡（个人使用过程影响不大，调优都是对view的刷选语句进行）。

这里在选择view或者synonym方式的时候就需要对view相关sql的性能进行了解，避免糟糕的性能对业务引起的不必要的影响，而view方式的调优都都在view本身这层。

Access control Oracle security | Guang Cai Li | |   01039 autot 简单的数据刷选

OS与密码认证

os认证和口令文件认证

1、os认证和口令文件认证其实质是对oracle数据库采取何种管理方式，是本地管理还是通过一台管理服务器统一管理。

本地管理采用的就是os认证方式，统一管理采用的就是口令文件认证方式

2、两种认证的实现

oracle数据库通过sqlnet.ora文件中的参数SQLNET.AUTHENTICATION_SERVICES，PFILE（或SPFILE）文件中的参数

REMOTE_LOGIN_PASSWORDFILE和口令文件PWDsid.ora三者协同作用实现身份认证。

SQLNET.AUTHENTICATION_SERVICES＝(NTS)|(NONE)

SQLNET.AUTHENTICATION_SERVICES＝(NTS): 操作系统认证方式，不使用口令文件

SQLNET.AUTHENTICATION_SERVICES＝(NONE)：口令文件认证方式

REMOTE_LOGIN_PASSWORDFILE=(‘NONE’)|(‘EXCLUSIVE’)|(‘SHARED’)

REMOTE_LOGIN_PASSWORDFILE=(‘NONE’)：不使用口令文件，操作系统认证

REMOTE_LOGIN_PASSWORDFILE=(‘EXCLUSIVE’)：口令文件认证方式，但只有一个数据库实例可以使用此文件，

系统允许将SYSOPER／SYSDBA授予除INTERNAL／SYS以外的其他用户，且以具有这类身份的其他用户登录是有效的

REMOTE_LOGIN_PASSWORDFILE=(‘SHARED’)：口令文件认证方式，可有多个数据库实例使用此文件，但是此设置下

只有INTERNAL／SYS帐号能被识别，即使文件中存有其他用户的信息，也不允许他们以SYSOPER／SYSDBA登录

1）SQLNET.AUTHENTICATION_SERVICES＝(NTS)同时REMOTE_LOGIN_PASSWORDFILE=(‘NONE’)，此时为操作系统

认证方式。

当以oracle_dba组下的用户登录进入本地windows2000后进行下边的操作：

sqlplus /nolog

sql>conn /as sysdba

或

sqlplus /nolog

sql>conn 任意用户名/密码 as sysdba

均可以sysdba身份登录成功，进行数据库方面的操作

当以远程进行登录时，执行

sqlplus /nolog

sql>conn /as sysdba

或

sqlplus /nolog

sql>conn sys/密码 as sysdba

均显示

“ERROR：

ORA-01031： insufficient privileges

”

也就是不允许以sysdba身份远程登录系统，这也是os认证之所以也称为本地认证方式的原因

2）SQLNET.AUTHENTICATION_SERVICES＝(NONE)同时REMOTE_LOGIN_PASSWORDFILE=(‘EXCLUSIVE’)或(‘SHARED’)，配合口令文件

PWDsid.ora，此时为口令文件认证方式

当在本地以oracle_dba组下的用户登录进入windows2000后进行下边的操作：

sqlplus /nolog

sql>conn /as sysdba

显示

“ERROR：

ORA-01031： insufficient privileges

”

实质上是要求提供拥有sysdba身份的用户名和密码

在本地或远程进行下边的操作

sqlplus “sys/密码@服务名 as sysdba”

可进入系统

也就是说口令文件认证方式允许用户从本地或远程以sysdba身份登录，但必须提供口令字

3）SQLNET.AUTHENTICATION_SERVICES＝(NTS)同时REMOTE_LOGIN_PASSWORDFILE=(‘EXCLUSIVE’)或(‘SHARED’)，配合口令文件

PWDsid.ora，此时操作系统认证和口令文件认证同时起作用

当在本地以oracle_dba组下的用户登录进入windows2000后进行下边的操作：

sqlplus /nolog

sql>conn /as sysdba

可进入系统

当在远程执行

sqlplus “sys/密码@服务名 as sysdba”

同样可正常登录到数据库系统上

上边的参数配置容易令人迷惑、混淆，造成假象。我推测网上有些朋友所以对身份认证产生费解可能就是因为这么

配置参数的！

三、其他

从前边的讨论可以知道，我们能够对sys以外的用户赋予sysdba身份，具体方法就是

SQLNET.AUTHENTICATION_SERVICES＝(NONE)

REMOTE_LOGIN_PASSWORDFILE=(‘EXCLUSIVE’)

口令文件PWDsid.ora

SQL>grant sysdba to 用户名

这样，其他具有sysdba身份的用户就加入到PWDsid.ora中，并可以被PWDsid.ora识别，我们可以用这个被赋予sysdba身份的用户登录并进行类似sys用户下所能执行的操作

NONE

Oracle ignores any password file. Therefore, privileged users must be authenticated by the operating system.

SHARED

More than one database can use a password file. However, the only user recognized by the password file is SYS.

EXCLUSIVE

The password file can be used by only one database and the password file can contain names other than SYS

Oracle security | Guang Cai Li |