自主访问控制(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预定义角色一起进行介绍。
数据库权限 | 说明 |
---|---|
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 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列出了主要的对象权限。
数据库对象类型 对象权限 | 表 | 视图 | 存储程序 | 包 | 类 | 类型 | 序列 | 目录 | 域 |
---|---|---|---|---|---|---|---|---|---|
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。
角色名称 | 角色简单说明 |
---|---|
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视图的查询权限 |
角色名称 | 角色简单说明 |
---|---|
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 <角色名>;
使用说明:
- 创建者必须具有CREATE ROLE数据库权限;
- 角色名的长度不能超过128个字符;
- 角色名不允许和系统已存在的用户名重名;
- 角色名不允许是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);
使用说明:
- 只有拥有ADMIN_ANY_ROLE权限的用户才能启用和禁用角色,并且设置后立即生效;
- 凡是包含禁用角色A的角色M,M中禁用的角色A将无效,但是M仍有效;
- 系统预设的角色是不能设置的,如:DBA、PUBLIC、RESOURCE。
当用户希望启用某个角色时,同样可以通过SP_SET_ROLE来启用角色,只要将第二个参数置为1即可。
例如,下面的语句将启用角色BOOKSHOP_ROLE1。
SP_SET_ROLE('BOOKSHOP_ROLE1', 1);
3.2.3 SVI角色用法
拥有SVI角色权限的用户可以查询V视图。V视图请参考《DM8系统管理员手册》。下面是使用SVI角色的相关系统过程。
- 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);
- 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)一起使用,才有效果。否则报错。
通常情况下,MANAGER创建的普通用户会同时具备SVI(此时SVI属于PUBLIC)、SOI和VTI角色权限。DIsql创建的普通用户同时具备SVI和SOI角色权限,无VTI权限。但是,在启用SVI角色(SP_SWITCH_SVI(1))的环境中,MANAGER创建的普通用户只有SVI(此时SVI属于PUBLIC)和VTI角色权限,DISQL创建的普通用户只有SVI,均无SOI角色,因此当后续禁用SVI功能后,必须给该普通用户授权SOI,否则不能查询SYS.数据字典表。例如,只能SELECT * FROM SYSOBJECTS; 而不能SELECT * FROM SYS.SYSOBJECTS;。
参数说明:
flag:1启用SVI;0禁用SVI
返回值:
启用返回1;禁用返回0
举例说明:
SP_SWITCH_SVI(0);
SP_SWITCH_SVI(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];
<特权> ::= <数据库权限>{,<数据库权限>};
<用户或角色>::= <用户名> | <角色名>
使用说明:
- 授权者必须具有对应的数据库权限以及其转授权;
- 接受者必须与授权者用户类型一致;
- 如果有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 <用户或角色>{,<用户或角色>} ;
<特权> ::= <数据库权限>{,<数据库权限>}
<用户或角色>::= <用户名> | <角色名>
使用说明:
- 权限回收者必须是具有回收相应数据库权限以及转授权的用户;
- 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
<对象> ::= [<模式名>.]<对象名>
<对象名> ::= <表名> | <视图名> | <存储过程/函数名> |<包名> |<类名> |<类型名> |<序列名> | <目录名> | <域名>
<用户或角色>::= <用户名> | <角色名>
使用说明:
- 授权者必须是具有对应对象权限以及其转授权的用户;
- 如未指定对象的<模式名>,模式为授权者所在的模式。DIRECTORY为非模式对象,没有模式;
- 如设定了对象类型,则该类型必须与对象的实际类型一致,否则会报错;
- 带WITH GRANT OPTION授予权限给用户时,则接受权限的用户可转授此权限;
- 不带列清单授权时,如果对象上存在同类型的列权限,会全部自动合并;
- 对于用户所在的模式的表,用户具有所有权限而不需特别指定;
- INDEX动作向其他用户授予指定表的创建和删除索引(包含全文索引)的权限;
- 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
使用说明:
- 权限回收者必须是具有回收相应对象权限以及转授权的用户;
- 回收时不能带列清单,若对象上存在同类型的列权限,则一并被回收;
- 使用GRANT OPTION FOR选项的目的是收回用户或角色权限转授的权利,而不回收用户或角色的权限;并且GRANT OPTION FOR选项不能和RESTRICT一起使用,否则会报错;
- 在回收权限时,设定不同的回收选项,其意义不同。具体如下:
- 若不设定回收选项,无法回收授予时带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];
<用户名或角色名> ::= <用户名> | <角色名>
使用说明:
- 角色的授予者必须为拥有相应的角色以及其转授权的用户;
- 接受者必须与授权者类型一致(譬如不能把审计角色授予标记角色);
- 支持角色的转授;
- 不支持角色的循环转授,如将BOOKSHOP_ROLE1授予BOOKSHOP_ROLE2,BOOKSHOP_ROLE2不能再授予BOOKSHOP_ROLE1。
例如,假设存在角色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 <角色名或用户名>;
<角色名或用户名> ::= <用户名> | <角色名>
使用说明:
- 权限回收者必须是具有回收相应角色以及转授权的用户;
- 使用ADMIN OPTION FOR选项的目的是收回用户或角色权限转授的权利,而不回收用户或角色的权限。
例如,接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暂不支持强制访问控制。