为什么PL / SQL不尊重角色授予的权限？

Question

执行PL / SQL块时，将忽略授予角色的任何权限。相反，您必须为特定用户提供特定授权才能运行它。如果我想让DBA访问包或函数或过程，我不能给DBA角色一个授权。我必须向DBA角色中的每个用户授予一个授权，如果他们不再是DBA，我必须删除用户的授权，并且我必须将授权添加到任何新的DBA。

我发现这很难维护。

我的问题是为什么PL / SQL以这种方式工作？ Oracle决定这是Roles和PL / SQL应该如何协同工作的设计考虑因素？我一直无法找到一个不是“那就是它的方式”的答案。

Answer 1

它可能是懒惰和SET ROLE命令的组合。

我不同意因为复杂的依赖关系而不允许这样做。 Oracle已经管理了复杂的依赖项。在12c中，可以为对象授予角色。

我认为对象不能继承用户角色的真正原因是SET ROLE命令。可以为用户分配角色，但在会话中打开和关闭它。这是一个愚蠢的功能，我从来没有见过它。但从理论上讲，它需要在同一个会话或事务中重新编译，这实在令人困惑。

Answer 2

也许我在这里没有正确理解某些东西，因为我做了你说不能做的事情。事实上，Oracle文档说它可以完成。请查看this document中有关过程安全性的部分。 （@ ibre5041）由于程序在所有者的特权下运行，因此无需重新编译任何内容。仅检查用户（或他的角色）权限是否允许他们运行该过程。 我错过了什么？

Answer 3

否则，如果删除某个角色，则PL / SQL包在某些情况下将变为INVALID（无需重新编译）。

DROP ROLE ...是DCL（数据控制语言）语句。看起来Oracle决定：“PL / SQL包不会被DCL语句变为无效”

Answer 4

我认为这是一些历史遗产。在更改ROLE的对象权限时，Oracle会重新编译大量的PL / SQL存储代码。 PS：你也可以创建名为＆＃34; SCHEMA＆＃34;。

的东西

请参阅CREATE SCHEMA声明。

Answer 5

我认为您可能会争夺Invokers权利与Definers权利。

来自Oracle docs：

  

在服务器调用期间，当DR单元被推入调用堆栈时，   数据库存储当前启用的角色和当前值   CURRENT_USER和CURRENT_SCHEMA。然后它会更改CURRENT_USER   和CURRENT_SCHEMA到DR单元的所有者，并仅启用   角色PUBLIC 。 （存储的和新的角色和值不一定   不同的。）当DR单元从调用堆栈弹出时，   数据库恢复存储的角色和值。相反，当一个IR   单元被推入或弹出调用堆栈，其值为   CURRENT_USER和CURRENT_SCHEMA，以及当前启用的角色   不要改变

因此，如果您希望Oracle尊重角色＆＃34;授予的权限，那么您可能希望使用Invokers权限（AUTHID CURRENT_USER子句）