首页 文章

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

提问于
浏览 次
3

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

我发现这很难维护 .

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

oracle plsql

5 回答

  • 1

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

    DROP ROLE ... 是DCL（数据控制语言）语句 . 看起来像Oracle决定："A PL/SQL package shall not become INVALID by a DCL statement"

    回复于
  • 2

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

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

    我认为对象不继承用户角色的真正原因是 SET ROLE 命令 . 它是一个愚蠢的功能，我从来没有见过它 . 但理论上，它需要在同一会话或事务中重新编译，这将是非常令人困惑的 .

    回复于
  • 1

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

    回复于
  • 0

    我认为这是一些历史遗产 . 当更改ROLE的对象privs时，Oracle会重新编译大量的PL / SQL存储代码 . PS：你也可以创建一个名为“SCHEMA”的东西 .

    见CREATE SCHEMA陈述 .

    回复于
  • 0

    我认为你可能会争夺Invokers权利与Definers的权利 .

    来自Oracle docs：

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

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

    回复于

相关问题