如何允许用户在数据库中查看授权、查看定义、PL/SQL 等,而不授予他们更改这些对象的访问权限

Sco*_*her 5 oracle

作为开发人员,我需要能够从生产中访问数据库/数据库对象的设计,这样我才能确保我正在使用我正在为其开发更改的最新和最好版本的对象(有助于避免不可预见的问题部署时)。

同样作为开发人员,我不应该有权修改、执行、更新、删除等这些对象——这是生产部署团队的工作。

作为 DBA,我如何提供对数据库设计的访问权限,以便开发人员可以验证他们正在进行的更改,而无需授予他们对数据库对象的全权访问权限?

作为一个具体的例子,我们的 DBA 已经充分锁定了生产环境,因此,在 TOAD 中,我看不到包的 PL/SQL 主体,看不到提供对对象访问的所有授权等。正在使用的用户帐户仅具有使用某些对象的有限访问权限,但无法查看开发人员开发更改所需的扩展详细信息。

我很想设置一些东西,所以我们有字典视图访问权限,允许我们查看所有授权、视图脚本、PL/SQL 包主体、表定义等,而不会给我们更多的访问权限生产(即,我们不应该改变任何这些东西)

是否有角色提供我们需要的访问权限、特权或一系列特权?如果没有,那么获取此类信息的一种好的替代方法是什么?

Jus*_*ave 10

SELECT ANY DICTIONARY 权限(或在早期版本中为 SELECT_CATALOG_ROLE 角色)授予用户从任何数据字典表中进行选择的权限。

SELECT ANY DICTIONARY 特权将授予开发人员特权,可以针对 DBA_SOURCE 编写他们想要的任何查询以查看任何对象的源,DBA_VIEWS 以查看视图定义等。但不能保证特定前端实际上会利用这些特权正确。太多的 GUI 只是从 ALL_* 数据字典表中选择来显示用户拥有对象权限的对象,而不是识别用户有权从 DBA_* 数据字典表中进行选择。就我个人而言,当我想查看生产数据库中的对象源时,我非常乐意查询 DBA_SOURCE 视图(或使用 DBMS_METADATA 包),但很多人在没有 GUI 模式浏览​​器的情况下会感到厌烦。

  • 在 11g 之前,SELECT ANY DICTIONARY 和 SELECT_CATALOG_ROLE 能够查看用户的散列密码。如果人们不使用复杂的密码,就会使他们容易受到蛮力攻击。DBA 不愿意授予他们是可以理解的。 (6认同)