看到 有人提问关于授权的问题. 不由得想多说几句. Oracle 9i 以及以下版本的数据库,默认的数据库角色有些不太合理的地方. DBA 管理的过程中,如果不太注意的话,可能会带来麻烦或者潜在的隐忧. 比如最常见的 CONNECT 角色.
User => FOO has been granted the following privileges
====================================================================
ROLE => CONNECT which contains =>
SYS PRIV => ALTER SESSION grantable => NO
SYS PRIV => CREATE CLUSTER grantable => NO
SYS PRIV => CREATE DATABASE LINK grantable => NO
SYS PRIV => CREATE SEQUENCE grantable => NO
SYS PRIV => CREATE SESSION grantable => NO
SYS PRIV => CREATE SYNONYM grantable => NO
SYS PRIV => CREATE TABLE grantable => NO
SYS PRIV => CREATE VIEW grantable => NO
这里面的 ALTER SESSION 就是一个问题. 恶意的用户很容易利用这个权限给系统带来麻烦.举两个例子,一个是 修改当前 Session 的 cursor_sharing 参数值为 FORCE ,然后提交可触发 Oracle Bug 的查询(cursor_sharing 在 FORCE 模式下 Bug 很多) , 很容易让数据库崩溃. 或者恶意用户提交 alter session set hash_area_size ... 的修改语句, 给自己设定一个超大的 HASH_AREA_SIZE , 再提交一定的查询,也会给系统性能造成很糟糕的影响.
这个 CONNECT 角色在 Oracle 10g 中已经修改了,只有 create session 的权限.
再来一个角色的问题. 比如 REOURCE 角色, 包含的权限如下所示:
User => FOO has been granted the following privileges
====================================================================
ROLE => RESOURCE which contains =>
SYS PRIV => CREATE CLUSTER grantable => NO
SYS PRIV => CREATE INDEXTYPE grantable => NO
SYS PRIV => CREATE OPERATOR grantable => NO
SYS PRIV => CREATE PROCEDURE grantable => NO
SYS PRIV => CREATE SEQUENCE grantable => NO
SYS PRIV => CREATE TABLE grantable => NO
SYS PRIV => CREATE TRIGGER grantable => NO
SYS PRIV => CREATE TYPE grantable => NO
SYS PRIV => UNLIMITED TABLESPACE grantable => NO
注意是包含 UNLIMITED TABLESPACE 权限的(实际上是隐含的一个权限,Oracle为什么这样做,没有明确的文档说明,在 10g 中为了向后兼容,也是这样的.), 恶意用户利用这个造成麻烦很容易:在 SYSTEM 建立一个足够大的表即可让数据库宕机.
所以,DBA 在给用户授权的时候还是谨慎为是,建议利用"最小授权原则", 只给用户必须的权限.
呵呵，我们的数据库安全性要求没那么高，
都没注意这些问题！
您好，您的博客内容十分优秀，我们在赞赏您能与他人分享生活快乐的同时,很荣幸的希望能够收录您的博客，愿您与众多中文博客共同分享生活的乐趣。
好博网中文目录编辑敬致
http://OkBlog.cn
从9i升级到10g,同样给用户connect和resource权限；
发现，到今天（1周半）发现少了
CREATE VIEW和DEBUG CONNECT SESSION 权限，需要显视的赋予。