自主访问控制

自主访问控制（Discretionary Access Control，DAC）是这样一种访问控制方式：由数据库对象的拥有者自主决定是否将自己拥有的对象的部分或全部访问权限授予其他用户。也就是说，在自主访问控制下，用户可以按照自己的意愿，有选择地与其他用户共享他拥有的数据库对象。

3.1 权限管理

DM 数据库对用户的权限管理有着严密的规定，如果没有权限，用户将无法完成任何操作。

用户权限有两类：数据库权限和对象权限。数据库权限主要是指针对数据库对象的创建、删除、修改的权限，对数据库备份等权限。而对象权限主要是指对数据库对象中的数据的访问权限。数据库权限一般由 SYSDBA、SYSAUDITOR 和 SYSSSO 指定，也可以由具有特权的其他用户授予。对象权限一般由数据库对象的所有者授予用户，也可由 SYSDBA 用户指定，或者由具有该对象权限的其他用户授权。

3.1.1 数据库权限

数据库权限是与数据库安全相关的非常重要的权限，其权限范围比对象权限更加广泛，因而一般被授予数据库管理员或者一些具有管理功能的角色。数据库权限与 DM 预定义角色有着重要的联系，一些数据库权限由于权力较大，只集中在几个 DM 系统预定义角色中，且不能转授，我们将在 3.2.1.1 中进行具体介绍。

DM 提供了 100 余种数据库权限，表 3.1 列出了最常用的几种数据库权限。完整的数据库权限列表将在 3.2.1.1 中与 DM 预定义角色一起进行介绍。

表3.1 常用的几种数据库权限
数据库权限 说明
CREATE TABLE 在自己的模式中创建表的权限
CREATE VIEW 在自己的模式中创建视图的权限
CREATE USER 创建用户的权限
CREATE TRIGGER 在自己的模式中创建触发器的权限
ALTER USER 修改用户的权限
ALTER DATABASE 修改数据库的权限
CREATE PROCEDURE 在自己模式中创建存储程序的权限

不同类型的数据库对象，其相关的数据库权限也不相同。

例如，对于表对象，相关的数据库权限包括：

  • CREATE TABLE：创建表
  • CREATE ANY TABLE：在任意模式下创建表
  • ALTER ANY TABLE：修改任意表
  • DROP ANY TABLE：删除任意表
  • INSERT TABLE：插入表记录
  • INSERT ANY TABLE：向任意表插入记录
  • UPDATE TABLE：更新表记录
  • UPDATE ANY TABLE：更新任意表的记录
  • DELETE TABLE：删除表记录
  • DELETE ANY TABLE：删除任意表的记录
  • SELECT TABLE：查询表记录
  • SELECT ANY TABLE：查询任意表的记录
  • REFERENCES TABLE：引用表
  • REFERENCES ANY TABLE：引用任意表
  • DUMP TABLE：导出表
  • DUMP ANY TABLE：导出任意表
  • GRANT TABLE：向其他用户进行表上权限的授权
  • GRANT ANY TABLE：向其他用户进行任意表上权限的授权

而对于存储程序对象，其相关的数据库权限则包括：

  • CREATE PROCEDURE：创建存储程序
  • CREATE ANY PROCEDURE：在任意模式下创建存储程序
  • DROP ANY PROCEDURE：删除任意存储程序
  • EXECUTE PROCEDURE：执行存储程序
  • EXECUTE ANY PROCEDURE：执行任意存储程序
  • GRANT PROCEDURE：向其他用户进行存储程序上权限的授权
  • GRANT ANY PROCEDURE：向其他用户进行任意存储程序上权限的授权

需要说明的是，表、视图、触发器、存储程序等对象为模式对象，在默认情况下对这些对象的操作都是在当前用户自己的模式下进行的。如果要在其他用户的模式下操作这些类型的对象，需要具有相应的 ANY 权限。例如，要能够在其他用户的模式下创建表，当前用户必须具有 CREATE ANY TABLE 数据库权限，如果希望能够在其他用户的模式下删除表，必须具有 DROP ANY TABLE 数据库权限。

建议

DM中有一个较特殊的数据库权限“CREATE SESSSION”，表示创建会话连接数据库的权限。系统预设的管理员用户都具备此权限，新建用户缺省也具备此权限，管理员可根据实际需要回收指定用户的CREATE SESSION权限以限制该用户连接数据库。

3.1.2 对象权限

对象权限主要是对数据库对象中的数据的访问权限，主要用来授予需要对某个数据库对象的数据进行操纵的数据库普通用户。表 3.2 列出了主要的对象权限。

表3.2 常用的对象权限
数据库对象类型 对象权限 表 视图 存储程序 包 类 类型 序列 目录 域
SELECT √ √ √
INSERT √ √
DELETE √ √
UPDATE √ √
REFERENCES √
DUMP √
EXECUTE √ √ √ √ √
READ √
WRITE √
USAGE √

SELECT、INSERT、DELETE 和 UPDATE 权限分别是针对数据库对象中的数据的查询、插入、删除和修改的权限。对于表和视图来说，删除操作是整行进行的，而查询、插入和修改却可以在一行的某个列上进行，所以在指定权限时，DELETE 权限只要指定所要访问的表就可以了，而 SELECT、INSERT 和 UPDATE 权限还可以进一步指定是对哪个列的权限。

表对象的 REFERENCES 权限是指可以与一个表建立关联关系的权限，如果具有了这个权限，当前用户就可以通过自己的一个表中的外键，与对方的表建立关联。关联关系是通过主键和外键进行的，所以在授予这个权限时，可以指定表中的列，也可以不指定。

存储程序等对象的 EXECUTE 权限是指可以执行这些对象的权限。有了这个权限，一个用户就可以执行另一个用户的存储程序、包、类等。

目录对象的 READ 和 WRITE 权限指可以读或写访问某个目录对象的权限。

域对象的 USAGE 权限指可以使用某个域对象的权限。拥有某个域的 USAGE 权限的用户可以在定义或修改表时为表列声明使用这个域。

当一个用户获得另一个用户的某个对象的访问权限后，可以以“模式名.对象名”的形式访问这个数据库对象。一个用户所拥有的对象和可以访问的对象是不同的，这一点在数据字典视图中有所反映。在默认情况下用户可以直接访问自己模式中的数据库对象，但是要访问其他用户所拥有的对象，就必须具有相应的对象权限。

对象权限的授予一般由对象的所有者完成，也可由 SYSDBA 或具有某对象权限且具有转授权限的用户授予，但最好由对象的所有者完成。

3.2 角色管理

角色是一组权限的组合，使用角色的目的是使权限管理更加方便。假设有 10 个用户，这些用户为了访问数据库，至少拥有 CREATE TABLE、CREATE VIEW 等权限。如果将这些权限分别授予这些用户，那么需要进行的授权次数是比较多的。但是如果把这些权限事先放在一起，然后作为一个整体授予这些用户，那么每个用户只需一次授权，授权的次数将大大减少，而且用户数越多，需要指定的权限越多，这种授权方式的优越性就越明显。这些事先组合在一起的一组权限就是角色，角色中的权限既可以是数据库权限，也可以是对象权限，还可以是别的角色。

为了使用角色，首先在数据库中创建一个角色，这时角色中没有任何权限。然后向角色中添加权限。最后将这个角色授予用户，这个用户就具有了角色中的所有权限。在使用角色的过程中，可以随时向角色中添加权限，也可以随时从角色中删除权限，用户的权限也随之改变。如果要回收所有权限，只需将角色从用户回收即可。

3.2.1 角色的创建与删除

3.2.1.1 DM 预定义角色

在 DM 数据库中有两类角色，一类是 DM 预设定的角色，一类是用户自定义的角色。DM 提供了一系列的预定义角色以帮助用户进行数据库权限的管理。预定义角色在数据库被创建之后即存在，并且已经包含了一些权限，数据库管理员可以将这些角色直接授予用户。

在“三权分立”和“四权分立”机制下，DM 的预定义角色及其所具有的权限是不相同的。表 3.3 和表 3.4 分别列出了“三权分立”和“四权分立”机制下常见的系统角色及其简单介绍，完整的预定义角色权限列表请参见附录 1 和附录 2。

表3.3 “三权分立”常见的数据库预设定的角色
角色名称 角色简单说明
DBA DM 数据库系统中对象与数据操作的最高权限集合，拥有构建数据库的全部特权，只有 DBA 才可以创建数据库结构
RESOURCE 可以创建数据库对象，对有权限的数据库对象进行数据操纵，不可以创建数据库结构
PUBLIC 不可以创建数据库对象，只能对有权限的数据库对象进行数据操纵
VTI 具有系统动态视图的查询权限，VTI 默认授权给 DBA 且可转授
SOI 具有系统表的查询权限
SVI 具有基础 V 视图的查询权限
DB_AUDIT_ADMIN 数据库审计的最高权限集合，可以对数据库进行各种审计操作，并创建新的审计用户
DB_AUDIT_OPER 可以对数据库进行各种审计操作，但不能创建新的审计用户
DB_AUDIT_PUBLIC 不能进行审计设置，但可以查询审计相关字典表
DB_AUDIT_VTI 具有系统动态视图的查询权限，DB_AUDIT_VTI 默认授权给 DB_AUDIT_ADMIN 且可转授
DB_AUDIT_SOI 具有系统表的查询权限
DB_AUDIT_SVI 具有基础 V 视图和审计 V 视图的查询权限
DB_POLICY_ADMIN 数据库强制访问控制的最高权限集合，可以对数据库进行强制访问控制管理，并创建新的安全管理用户
DB_POLICY_OPER 可以对数据库进行强制访问控制管理，但不能创建新的安全管理用户
DB_POLICY_PUBLIC 不能进行强制访问控制管理，但可以查询强制访问控制相关字典表
DB_POLICY_VTI 具有系统动态视图的查询权限，DB_POLICY_VTI 默认授权给 DB_POLICY_ADMIN 且可转授
DB_POLICY_SOI 具有系统表的查询权限
DB_POLICY_SVI 具有基础 V 视图和安全 V 视图的查询权限
表3.4 “四权分立”常见的数据库预设定的角色
角色名称 角色简单说明
DBA 拥有构建数据库的全部特权，只有 DBA 才可以创建数据库结构
RESOURCE 可以创建和删除角色
PUBLIC 只能查询相关的数据字典表
VTI 具有系统动态视图的查询权限，VTI 默认授权给 DBA 且可转授
SOI 具有系统表的查询权限
SVI 具有基础 V 视图的查询权限
DB_AUDIT_ADMIN 数据库审计的最高权限集合，可以对数据库进行各种审计操作，并创建新的审计用户
DB_AUDIT_OPER 可以对数据库进行各种审计操作，但不能创建新的审计用户
DB_AUDIT_PUBLIC 不能进行审计设置，但可以查询审计相关字典表
DB_AUDIT_VTI 具有系统动态视图的查询权限，DB_AUDIT_VTI 默认授权给 DB_AUDIT_ADMIN 且可转授
DB_AUDIT_SOI 具有系统表的查询权限
DB_AUDIT_SVI 具有基础 V 视图和审计 V 视图的查询权限
DB_POLICY_ADMIN 数据库强制访问控制的最高权限集合，可以对数据库进行强制访问控制管理，并创建新的安全管理用户
DB_POLICY_OPER 可以对数据库进行强制访问控制管理，但不能创建新的安全管理用户
DB_POLICY_PUBLIC 不能进行强制访问控制管理，但可以查询强制访问控制相关字典表
DB_POLICY_VTI 具有系统动态视图的查询权限，DB_POLICY_VTI 默认授权给 DB_POLICY_ADMIN 且可转授
DB_POLICY_SOI 具有系统表的查询权限
DB_POLICY_SVI 具有基础 V 视图和安全 V 视图的查询权限
DB_OBJECT_ADMIN 可以在自己的模式下创建各种数据库对象并进行数据操纵，也可以创建和删除非模式对象
DB_OBJECT_OPER 可以在自己的模式下创建数据库对象并进行数据操纵
DB_OBJECT_PUBLIC 不可以创建数据库对象，只能对有权限的数据库对象进行数据操纵
DB_OBJECT_VTI 具有系统动态视图的查询权限，DB_OBJECT_VTI 默认授权给 DB_OBJECT_ADMIN 且可转授
DB_OBJECT_SOI 具有系统表的查询权限
DB_OBJECT_SVI 和 SVI 权限一样

我们可以认为“三权分立”安全机制将用户分为了三种类型，“四权分立”安全机制将用户分为了四种类型，每种类型又各对应六种预定义角色。如：

  • DBA 类型对应 DBA、RESOURCE、PUBLIC、VTI、SOI、SVI 预定义角色；
  • AUDITOR 对应 DB_ADUTI_ADMIN、DB_AUDIT_OPER、DB_AUDIT_PUBLIC、DB_AUDIT_VTI、DB_AUDIT_SOI、DB_AUDIT_SVI 预定义角色；
  • SSO 对应 DB_POLICY_ADMIN、DB_POLICY_OPER、DB_POLICY_PUBLIC、DB_POLICY_VTI、DB_POLICY_SOI、DB_POLICY_SVI 预定义角色；
  • DBO 对应 DB_OBJECT_ADMIN、DB_OBJECT_OPER、DB_OBJECT_PUBLIC、DB_OBJECT_VTI、DB_OBJECT_SOI、DB_OBJECT_SVI 预定义角色。

初始时仅有管理员具有创建用户的权限，每种类型的管理员创建的用户缺省就拥有这种类型的 PUBLIC 和 SOI 预定义角色，如 SYSAUDITOR 新创建的用户缺省就具有 DB_AUDIT_PUBLIC 和 DB_AUDIT_SOI 角色。之后管理员可根据需要进一步授予新建用户其他预定义角色。

管理员也可以将“CREATE USER”权限转授给其他用户，这些用户之后就可以创建新的用户了，他们创建的新用户缺省也具有与其创建者相同类型的 PUBLIC 和 SOI 预定义角色。

■ 限制 DBA 的“ANY”权限

从附录 1 和附录 2 的表中我们可以看到，缺省情况下，DBA 角色拥有许多的“ANY”权限，如 DROP ANY TABLE、INSERT ANY TABLE 等等。DM 提供了一种限制 DBA 的“ANY”权限的方法：在非 DM 安全版本中，只有 SYSDBA 用户才能限制 DBA 的“ANY”权限；在 DM 安全版本中，只有具有 DB_POLICY_ADMIN 角色的用户才能限制 DBA 的“ANY”权限。通过执行下面的系统过程来实现，系统过程执行完成后需要重启服务器该限制才能生效。

VOID
SP_RESTRICT_DBA(
	FLAG INT
);

参数 FLAG 置为 1 表示限制 DBA 的“ANY”权限，此过程执行后所有的 DBA 用户将不再具有“ANY”权限；FLAG 置为 0 表示不限制 DBA 的“ANY”权限。

3.2.1.2 创建角色

具有“CREATE ROLE”数据库权限的用户也可以创建新的角色，其语法如下：

CREATE ROLE <角色名>;

使用说明：

  1. 创建者必须具有 CREATE ROLE 数据库权限；
  2. 角色名的长度不能超过 128 个字符；
  3. 角色名不允许和系统已存在的用户名重名；
  4. 角色名不允许是 DM 保留字。

例如，创建角色 BOOKSHOP_ROLE1，赋予其 PERSON.ADDRESS 表的 SELECT 权限。

CREATE ROLE BOOKSHOP_ROLE1;
GRANT SELECT ON PERSON.ADDRESS TO BOOKSHOP_ROLE1;

3.2.1.3 删除角色

具有“DROP ROLE”权限的用户可以删除角色，其语法如下：

DROP ROLE [IF EXISTS] <角色名>;

即使已将角色授予了其他用户，删除这个角色的操作也将成功。此时，那些之前被授予该角色的用户将不再具有这个角色所拥有的权限，除非用户通过其他途径也获得了这个角色所具有的权限。

指定 IF EXISTS 关键字后，删除不存在的角色时不会报错，否则会报错。

例如，接上一小节的例子。将角色 BOOKSHOP_ROLE1 授予用户 BOOKSHOP_USER，则用户 BOOKSHOP_USER 具有了 SELECT 表 PERSON.ADDRESS 的权限。此时删除角色 BOOKSHOP_ROLE1，那么用户 BOOKSHOP_USER 将不再能查询表 PERSON.ADDRESS。但是如果用户 BOOKSHOP_USER 从别的途径（直接授权或通过别的角色授权）重复获得了 SELECT 表 PERSON.ADDRESS 的权限，那么即使删除了角色 BOOKSHOP_ROLE1，用户 BOOKSHOP_USER 仍然具有 SELECT 表 PERSON.ADDRESS 的权限。

3.2.2 角色的启用与禁用

某些时候，用户不愿意删除一个角色，但是却希望这个角色失效，此时可以使用 DM 系统过程 SP_SET_ROLE 来设置这个角色为不可用，将第二参数置为 0 表示禁用角色。

例如，下面的语句将角色 BOOKSHOP_ROLE1 禁用。

SP_SET_ROLE('BOOKSHOP_ROLE1', 0);

使用说明：

  1. 只有拥有 ADMIN_ANY_ROLE 权限的用户才能启用和禁用角色，并且设置后立即生效；
  2. 凡是包含禁用角色 A 的角色 M，M 中禁用的角色 A 将无效，但是 M 仍有效；
  3. 系统预设的角色是不能设置的，如：DBA、PUBLIC、RESOURCE。

当用户希望启用某个角色时，同样可以通过 SP_SET_ROLE 来启用角色，只要将第二个参数置为 1 即可。

例如，下面的语句将启用角色 BOOKSHOP_ROLE1。

SP_SET_ROLE('BOOKSHOP_ROLE1', 1);

3.2.3 SVI 角色用法

拥有 SVI 角色权限的用户可以查询 V 视图。V 视图请参考《DM8 系统管理员手册》。下面是使用 SVI 角色的相关系统过程。

  1. SP_INIT_SVI_SYS

定义：

SP_INIT_SVI_SYS(

CREATE_FLAG   int

)

功能说明：

可以手动重建所有 V 视图，并授权给 SVI、DB_POLICY_SVI、DB_OBJECT_SVI 和 DB_AUDIT_SVI。只有 DBA 和 DB_OBJECT_ADMIN 可以执行。

参数详解

CREATE_FLAG：1 重建所有 V 视图；0 删除所有 V 视图

返回值

无

举例说明

SP_INIT_SVI_SYS(1);

SP_INIT_SVI_SYS(0);
  1. SP_SWITCH_SVI

定义：

SP_SWITCH_SVI(

flag      int

)

功能说明：

SVI 角色启用或禁用。只有 DBA/DB_OBJECT_ADMIN 可以执行。SVI 启用时字典信息来源于 V 视图， 禁用字典信息来源于 SYS.数据字典表。

SP_INIT_SVI_SYS(1)需和 SP_SWITCH_SVI(1)一起使用，SP_INIT_SVI_SYS(0)需和 SP_SWITCH_SVI(0)一起使用，才有效果。否则报错。

SP_SWITCH_SVI 会对 MANAGER 工具造成访问影响，所以建议调用后立即重启数据库。

参数说明：

flag：1 启用 SVI；0 禁用 SVI

返回值：

启用返回 1；禁用返回 0

举例说明：

SP_SWITCH_SVI(0); 

SP_SWITCH_SVI(1);
  1. SF_GET_SVI

定义：

SF_GET_SVI ()

功能说明：

获取当前系统是否启用 SVI 角色 。

参数说明：

无

返回值：

启用返回 1；禁用返回 0

举例说明：

SP_SWITCH_SVI(0); 
SELECT SF_GET_SVI;  //结果为0
SP_SWITCH_SVI(1); 
SELECT SF_GET_SVI;  //结果为1

3.3 权限的分配与回收

可以通过 GRANT 语句将权限（包括数据库权限、对象权限以及角色权限）分配给用户和角色，之后也可以使用 REVOKE 语句将授出的权限再进行回收。

3.3.1 数据库权限的分配与回收

3.3.1.1 数据库权限的分配

可以使用 GRANT 语句授予用户和角色数据库权限。

数据库权限的授权语句语法为：

GRANT <特权> TO <用户或角色>{,<用户或角色>} [WITH ADMIN OPTION];
<特权> ::= <数据库权限>{,<数据库权限>};
<用户或角色>::= <用户名> | <角色名>

使用说明：

  1. 授权者必须具有对应的数据库权限以及其转授权；
  2. 接受者必须与授权者用户类型一致；
  3. 如果有 WITH ADMIN OPTION 选项，接受者可以再把这些权限转授给其他用户/角色。

例如，系统管理员 SYSDBA 把建表和建视图的权限授给用户 BOOKSHOP_USER1，并允许其转授。

GRANT CREATE TABLE, CREATE VIEW TO BOOKSHOP_USER1 WITH ADMIN OPTION;

3.3.1.2 数据库权限的回收

可以使用 REVOKE 语句回收授出的指定数据库权限。

回收数据库权限的语句语法为：

REVOKE [ADMIN OPTION FOR]<特权> FROM <用户或角色>{,<用户或角色>} ;
<特权> ::= <数据库权限>{,<数据库权限>}
<用户或角色>::= <用户名> | <角色名>

使用说明：

  1. 权限回收者必须是具有回收相应数据库权限以及转授权的用户；
  2. ADMIN OPTION FOR 选项的意义是取消用户或角色的转授权限，但是权限不回收。

例 1 接 3.3.1.1 中的例子，现在 SYSDBA 把用户 BOOKSHOP_USER1 的建表权限收回。

REVOKE CREATE TABLE FROM BOOKSHOP_USER1;

例 2 接 3.3.1.1 中的例子，之前 SYSDBA 把建视图的权限授给了用户 BOOKSHOP_USER1，并且允许转授。现在 SYSDBA 不让用户 BOOKSHOP_USER1 转授 CREATE VIEW 权限。

REVOKE ADMIN OPTION FOR CREATE VIEW FROM BOOKSHOP_USER1;

BOOKSHOP_USER1 仍有 CREATE VIEW 权限，但是不能将 CREATE VIEW 权限转授给其他用户。

3.3.1.3 限制相关数据库权限的授予与回收

通过 INI 参数 ENABLE_DDL_ANY_PRIV 限制 DDL 相关的 ANY 数据库权限的授予与回收，有 2 个取值：

  • 1：可以授予和回收 DDL 相关的 ANY 系统权限；
  • 0：不可以授予和回收 DDL 相关的 ANY 系统权限。缺省为 0。

例 1 当 ENABLE_DDL_ANY_PRIV=0 时，禁止授予或回收 create any trigger 的权限。

CONN SYSDBA/SYSDBA
create user DBSEC  identified by 123456789;
GRANT create any trigger TO DBSEC; //报错
revoke create any trigger from DBSEC;//报错

3.3.2 对象权限的分配与回收

3.3.2.1 对象权限的分配

可以使用 GRANT 语句将对象权限授予用户和角色。

对象权限的授权语句语法为：

GRANT <特权> ON [<对象类型>] <对象> TO <用户或角色>{,<用户或角色>} [WITH GRANT OPTION];
<特权>::= ALL [PRIVILEGES] | <动作> {, <动作>}
<动作>::= SELECT[(<列清单>)] |
        INSERT[(<列清单>)] | 
        UPDATE[(<列清单>)] | 
        DELETE | 
        REFERENCES[(<列清单>)] |
        EXECUTE|
        READ|
        WRITE|
        USAGE|
        INDEX|
        ALTER
<列清单>::= <列名> {,<列名>}
<对象类型>::= TABLE | VIEW | PROCEDURE | PACKAGE | CLASS | TYPE | SEQUENCE | DIRECTORY | DOMAIN 
<对象> ::= [<模式名>.]<对象名>
<对象名> ::= <表名> | <视图名> | <存储过程/函数名> |<包名> |<类名> |<类型名> |<序列名> | <目录名> | <域名>
<用户或角色>::= <用户名> | <角色名>

使用说明：

  1. 授权者必须是具有对应对象权限以及其转授权的用户；
  2. 如未指定对象的<模式名>，模式为授权者所在的模式。DIRECTORY 为非模式对象，没有模式；
  3. 如设定了对象类型，则该类型必须与对象的实际类型一致，否则会报错；
  4. 带 WITH GRANT OPTION 授予权限给用户时，则接受权限的用户可转授此权限；
  5. 不带列清单授权时，如果对象上存在同类型的列权限，会全部自动合并；
  6. 对于用户所在的模式的表，用户具有所有权限而不需特别指定；
  7. INDEX 动作向其他用户授予指定表的创建和删除索引（包含全文索引）的权限；
  8. ALTER 动作仅支持向其他用户授予指定表的修改权限。

当授权语句中使用了 ALL PRIVILEGES 时，会将指定的数据库对象上所有的对象权限都授予被授权者。不同类型的数据库对象相关的对象权限见 3.1.2 节的介绍。

例 1 SYSDBA 把 PERSON.ADDRESS 表的全部权限授给用户 BOOKSHOP_USER1。

GRANT SELECT, INSERT, DELETE, UPDATE, REFERENCES ON PERSON.ADDRESS TO BOOKSHOP_USER1;

该语句也可写为以下形式：

GRANT ALL PRIVILEGES ON PERSON.ADDRESS TO BOOKSHOP_USER1;

例 2 假设用户 BOOKSHOP_USER1 创建了存储过程 BOOKSHOP_USER1_PROC1，数据库管理员 SYSDBA 把该存储过程的执行权 EXECUTE 授给已存在用户 BOOKSHOP_USER2，并使其具有该权限的转授权。

GRANT EXECUTE ON PROCEDURE BOOKSHOP_USER1.BOOKSHOP_USER1_PROC1 TO BOOKSHOP_USER2 WITH GRANT OPTION;

例 3 假设 SYSDBA 是表 BOOKSHOP_T1 的创建者，用户 BOOKSHOP_USER1、BOOKSHOP_USER2、BOOKSHOP_USER3 存在，且都不是 DBA 权限用户。

(1)以SYSDBA身份登录，并执行语句：
GRANT SELECT ON BOOKSHOP_T1 TO BOOKSHOP_USER1 WITH GRANT OPTION;
//正确

(2)以BOOKSHOP_USER1身份登录，并执行语句：
GRANT SELECT ON SYSDBA.BOOKSHOP_T1 TO BOOKSHOP_USER2;
//正确

(3)以BOOKSHOP_USER2身份登录，并执行语句：
GRANT SELECT ON SYSDBA.BOOKSHOP_T1 TO BOOKSHOP_USER3;
//错误，用户BOOKSHOP_USER2没有SELECT权限的转授权

例 4
用户 SYSDBA 创建一个名为 VIEW_PRODUCT 的视图，要求对于该视图，允许 BOOKSHOP_USER1 能够进行查询、插入、删除和更新操作，用户 BOOKSHOP_USER2 和 BOOKSHOP_USER3 也可进行同样的工作，但要求其操作权限由用户 BOOKSHOP_USER1 控制。

(1)以SYSDBA的身份登录：
CREATE VIEW VIEW_PRODUCT AS
SELECT * FROM PRODUCTION.PRODUCT
WHERE NOWPRICE>=20 AND ORIGINALPRICE<40 WITH CHECK OPTION;
GRANT SELECT, INSERT, DELETE, UPDATE ON VIEW_PRODUCT
TO BOOKSHOP_USER1 WITH GRANT OPTION;

(2)以用户BOOKSHOP_USER1的身份登录：
GRANT SELECT, INSERT, DELETE, UPDATE ON SYSDBA.VIEW_PRODUCT TO BOOKSHOP_USER2,
BOOKSHOP_USER3;

例 5 假定表的创建者 SYSDBA 把所创建的 PRODUCTION.PRODUCT 表的部分列的更新权限授予用户 BOOKSHOP_USER1，BOOKSHOP_USER1 再将此更新权限转授给用户 BOOKSHOP_USER2。

(1)以SYSDBA的身份登录，并执行语句：
GRANT UPDATE (ORIGINALPRICE, NOWPRICE) ON PRODUCTION.PRODUCT TO BOOKSHOP_USER1
WITH GRANT OPTION;

(2)以BOOKSHOP_USER1的身份登录，并执行语句，把列级更新权限授给用户BOOKSHOP_USER2：
GRANT UPDATE(ORIGINALPRICE, NOWPRICE)ON PRODUCTION.PRODUCTTO BOOKSHOP_USER2;

3.3.2.2 对象权限的回收

可以使用 REVOKE 语句回收授出的指定数据库对象的指定权限。

对象权限的回收语句语法为：

REVOKE [GRANT OPTION FOR] <特权> ON [<对象类型>]<对象> FROM <用户或角色> {,<用户或角色>} [<回收选项>];
<特权>::= ALL [PRIVILEGES] | <动作> {, <动作>}
<动作>::= SELECT |
        INSERT | 
        UPDATE | 
        DELETE | 
        REFERENCES |
        EXECUTE|
        READ|
        WRITE|
        USAGE|
        INDEX|
        ALTER
<对象类型>::= TABLE | VIEW | PROCEDURE | PACKAGE | CLASS | TYPE | SEQUENCE | DIRECTORY | DOMAIN 
<对象> ::= [<模式名>.]<对象名>
<对象名> ::= <表名> | <视图名> | <存储过程/函数名> |<包名> |<类名> |<类型名> | <序列名> | <目录名> | <域名>
<用户或角色>::= <用户名> | <角色名>
<回收选项> ::= RESTRICT | CASCADE

使用说明：

  1. 权限回收者必须是具有回收相应对象权限以及转授权的用户；
  2. 回收时不能带列清单，若对象上存在同类型的列权限，则一并被回收；
  3. 使用 GRANT OPTION FOR 选项的目的是收回用户或角色权限转授的权利，而不回收用户或角色的权限；并且 GRANT OPTION FOR 选项不能和 RESTRICT 一起使用，否则会报错；
  4. 在回收权限时，设定不同的回收选项，其意义不同。具体如下：
  • 若不设定回收选项，无法回收授予时带 WITH GRANT OPTION 的权限，但也不会检查要回收的权限是否存在限制；
  • 若设定为 RESTRICT，无法回收授予时带 WITH GRANT OPTION 的权限，也无法回收存在限制的权限，如角色上的某权限被别的用户用于创建视图等；
  • 若设定为 CASCADE，可回收授予时带或不带 WITH GRANT OPTION 的权限，若带 WITH GRANT OPTION 还会引起级联回收。利用此选项时也不会检查权限是否存在限制。另外，利用此选项进行级联回收时，若被回收对象上存在另一条路径授予同样权限给该对象时，则仅需回收当前权限。
建议

用户A给用户B授权且允许其转授，B将权限转授给C。当A回收B的权限的时候必须加CASCADE回收选项。

例 1 接 3.3.2.1 节例 1，SYSDBA 从用户 BOOKSHOP_USER1 处回收其授出的 PERSON.ADDRESS 表的全部权限。

REVOKE ALL PRIVILEGES ON BOOKSHOP_T1 FROM BOOKSHOP_USER1 CASCADE;

例 2 接 3.3.2.1 节例 2，SYSDBA 从用户 BOOKSHOP_USER2 处回收其授出的存储过程 BOOKSHOP_USER1_PROC1 的 EXECUTE 权限。

REVOKE EXECUTE ON PROCEDURE BOOKSHOP_USER1.BOOKSHOP_USER1_PROC1
FROM BOOKSHOP_USER2 CASCADE;

例 3 假定系统中存在非 SYSDBA 用户 BOOKSHOP_USER1、BOOKSHOP_USER2、BOOKSHOP_USER3 和 BOOKSHOP_USER4，其中 BOOKSHOP_USER1 具有 CREATE TABLE 数据库权限，BOOKSHOP_USER2 具有 CREATE VIEW 数据库权限，且已成功执行了如下的语句：

BOOKSHOP_USER1登录执行:
CREATE TABLE T1(ID INT, NAME VARCHAR(100));
GRANT SELECT ON T1 TO PUBLIC;
GRANT INSERT(ID) ON T1 TO BOOKSHOP_USER2 WITH GRANT OPTION;
BOOKSHOP_USER2登录执行:
CREATE VIEW V1 AS SELECT NAME FROM BOOKSHOP_USER1.T1 WHERE ID < 10;
BOOKSHOP_USER3登录执行:
GRANT INSERT(ID) ON BOOKSHOP_USER1.T1 TO BOOKSHOP_USER4 WITH GRANT OPTION;
BOOKSHOP_USER4登录执行:
GRANT INSERT(ID) ON BOOKSHOP_USER1.T1 TO BOOKSHOP_USER2 WITH GRANT OPTION;

此时，若 BOOKSHOP_USER1 执行以下语句会引起之前授予的 INSERT(ID)权限被合并。

GRANT INSERT ON T1 TO BOOKSHOP_USER2 WITH GRANT OPTION;

若 BOOKSHOP_USER1 执行以下语句，会成功，因为这种方式不检查权限是否存在限制。

REVOKE SELECT ON T1 FROM PUBLIC;

若 BOOKSHOP_USER1 执行以下语句，则会失败，因为这种方式检查权限是否存在限制，即 BOOKSHOP_USER2 利用此权限创建了视图 V1。

REVOKE SELECT ON T1 FROM PUBLIC RESTRICT;

若 BOOKSHOP_USER1 执行以下语句，会进行级联回收 BOOKSHOP_USER2、BOOKSHOP_USER3、BOOKSHOP_USER4 授出的 INSERT(ID)权限。

REVOKE INSERT ON T1 FROM BOOKSHOP_USER2 CASCADE;

但若 BOOKSHOP_USER1 连续执行了以下两条语句，则后一条语句仅回收其授予 BOOKSHOP_USER2 的权限，而不会产生级联回收，因为有另一条路经授予了 BOOKSHOP_USER3 同样的权限 INSERT(ID)。

GRANT INSERT ON T1 TO BOOKSHOP_USER3 WITH GRANT OPTION;
REVOKE INSERT ON T1 FROM BOOKSHOP_USER2 CASCADE;

3.3.3 角色权限的分配与回收

3.3.3.1 角色权限的分配

通常角色包含权限或其他角色，通过使用 GRANT 语句将一个角色授予用户或另一角色可以使得用户和角色继承该角色所具有的权限。

授予角色权限的语句语法如下：

GRANT <角色名>{, <角色名>} TO <用户或角色>{,<用户或角色>} [WITH  ADMIN OPTION];
<用户名或角色名> ::= <用户名> | <角色名>

使用说明：

  1. 角色的授予者必须为拥有相应的角色以及其转授权的用户；
  2. 接受者必须与授权者类型一致(譬如不能把审计角色授予标记角色)；
  3. 支持角色的转授；
  4. 不支持角色的循环转授，如将 BOOKSHOP_ROLE1 授予 BOOKSHOP_ROLE2，BOOKSHOP_ROLE2 不能再授予 BOOKSHOP_ROLE1；
  5. 支持对系统角色授权系统权限。但是不支持再为 PUBLIC 系统角色授予在 dminit 初始化时已经被授予的系统权限（INSERT TABLE、UPDATE TABLE、DELETE TABLE、SELECT TABLE、DUMP TABLE、REFERENCE TABLE、GRANT TABLE、INSERT VIEW、UPDATE VIEW、DELETE VIEW、SELECT VIEW、GRANT VIEW、EXECUTE PROCEDURE、GRANT PROCEDURE、SELECT SEQUENCE、GRANT SEQUENCE、EXECUTE PACKAGE、GRANT PACKAGE、SELECT MATERIALIZED VIEW、GRANT DOMAIN、USAGE DOMAIN），也不支持为 PUBLIC 角色授予 SVI 角色。

例如，假设存在角色 BOOKSHOP_ROLE1，角色 BOOKSHOP_ROLE2，用户 BOOKSHOP_USER1。

//让用户BOOKSHOP_USER1继承角色BOOKSHOP_ROLE1的权限
GRANT BOOKSHOP_ROLE1 TO BOOKSHOP_USER1;

//让角色BOOKSHOP_ROLE2继承角色BOOKSHOP_ROLE1的权限
GRANT BOOKSHOP_ROLE1 TO BOOKSHOP_ROLE2;

3.3.3.2 角色权限的回收

可以使用 REVOKE 语句回收用户或其它角色从指定角色继承过来的权限。

回收角色权限的语句语法为：

REVOKE [ADMIN OPTION FOR] <角色名>{,<角色名>} FROM <角色名或用户名>;
<角色名或用户名> ::= <用户名> | <角色名>

使用说明：

  1. 权限回收者必须是具有回收相应角色以及转授权的用户；
  2. 使用 ADMIN OPTION FOR 选项的目的是收回用户或角色权限转授的权利，而不回收用户或角色的权限；
  3. 支持对系统角色回收系统权限。但是不支持回收 PUBLIC 系统角色中在 dminit 初始化时已经被授予的系统权限，也不支持回收 PUBLIC 角色的 SVI 角色。

例如，接 3.3.3.1 节的例子，回收用户 BOOKSHOP_USER1 和角色 BOOKSHOP_ROLE2 的 BOOKSHOP_ROLE1 角色。

REVOKE BOOKSHOP_ROLE1 FROM BOOKSHOP_USER1;
REVOKE BOOKSHOP_ROLE1 FROM BOOKSHOP_ROLE2;

4 强制访问控制

强制访问控制(Mandatory Access Control, MAC)是根据客体的敏感标记和主体的访问标记对客体访问实行限制的一种方法。在强制访问控制中，系统给主体和客体都分配一个特殊的安全标记，主体的安全标记反映了该主体可信的程度，客体的安全标记则与其包含信息的敏感度一致，且主体不能改变他自己及任何其它客体的安全标记，主体是否可以对客体执行特定的操作取决于主体和客体的安全标记之间的支配关系。因此，强制访问控制可以控制系统中信息流动的轨迹，能有效地抵抗特洛伊木马的攻击，这在一些对安全要求很高的数据库应用中是非常必要的。

DM 利用策略和标记来实现 DM 数据库的强制访问控制。执行强制访问控制的用户必须具有 LABEL_DATABASE 数据库权限，在新初始化的数据库中，只有 SYSSSO 具有这个权限。

强制访问控制功能仅在 DM 安全版中提供。DM 共享存储集群 DMDSC、DM 数据守护和读写分离集群都支持强制访问控制，但 DM 大规模并行处理集群 MPP 暂不支持强制访问控制。

微信扫码
分享文档
扫一扫
联系客服