【问题标题】:Granting permission to users on different schema向不同架构上的用户授予权限
【发布时间】:2017-10-30 18:07:54
【问题描述】:

我在模式 A 中有表。我使用模式 A 中的表在模式 B 中创建了视图。

我想授予用户从架构 B 的视图中选择数据的权限。

为此,我知道我们必须为用户 B 启用模式 A 中表的授权选项。 但我想在一个脚本中完成(这个脚本必须在模式 B 中)。有没有办法使用模式 A 的用户名/密码来做到这一点。

【问题讨论】:

  • 没有意义 - 架构中不存在脚本,它们只是您连接到实例的用户有权运行的命令列表。 IIRC 授权语句是每个对象(即:表)。请重新表述您的问题,以便更清楚您的问题。

标签: oracle


【解决方案1】:

希望有一个脚本来部署更改并不罕见。问题是,这样的脚本需要由高级用户运行,因为它需要具有 ANY 级别的系统权限。这通常意味着 DBA 帐户,最好是应用程序帐户,否则是 SYSTEM 或 SYS。

所以你想要的脚本应该是这样的:

grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from   user_a.t42
       join user_a.t23
           on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/

一个常见的情况是,我们有一套单独的脚本,它们被编写为由不同的用户运行,但我们现在需要将它们捆绑到一个部署中。原始脚本不包含模式名称,我们不想在脚本中硬编码它们有很多很好的理由。

构建该主脚本的一种方法是使用更改 CURRENT_SCHEMA 语法:

alter session set current_schema=USER_A
/
@run_grants_to_userb.sql

alter session set current_schema=USER_B
/
@create_view69.sql
@run_grants_to_userc.sql

我们仍然需要一个 DBA 用户来运行主脚本。切换当前模式的一个优点是它允许我们部署像数据库链接这样的对象,通过一种奇怪的语法,它们的声明中不能有模式名称。一个问题是用户不会改变,因此使用 USER 伪列的脚本可能会产生不需要的结果。

【讨论】:

  • 我很确定 USER 关键字在运行时解析,而不是在部署时解析。因此,如果您有一列显示“用户”,它将返回执行 SQL 的用户的 ID,而不是部署视图的用户。仍然 - 即使具体示例不相关,我也理解您在原则上提出的观点。
  • @cartbeforehorse - 老实说,我不记得我多年前试图提出的观点。我想我想到了类似create table t1 as select * from t where col1 = user; 的脚本。
  • 是的 - 如果您创建了一个表并使用“用户”过滤的数据预填充它,那么加载到该表中的数据将仅与创建表的用户相关(而不是用户谁随后访问它)。但这是一个非常具体的用例:-P [PS 抱歉挖掘过去 - 我在回复之前不看时间戳。我认为这里的一切都是永恒的]
【解决方案2】:

只需运行查询

将表 1 上的插入、选择、更新、删除授予 SCHEMA2;

【讨论】:

    【解决方案3】:

    只能在某个时候以用户 A 的身份连接。如果您真的想这样做,您仍然可以在一个脚本中完成:

    connect userA/passwordA
    grant select on my_table to userB;
    connect userB/passwordB
    create view my_view as select * from userA.my_table;
    

    当然,现在您有一个脚本,它向任何可以阅读它的人公开两组用户凭据。例如,在投入生产之前需要认真考虑一些事情。

    如果您希望其他用户能够从视图中进行选择,则无需将userA.my_table 的显式权限授予他们;只要视图所有者可以看到基础表,其他用户只需要能够看到视图。这通常是重点(或其中之一),因为您可以将视图限制为仅将基础表中的选定数据公开给世界其他地方。我假设您有理由不在架构 A 中创建视图。

    我不确定您是否真的想通过管理员选项向用户 B 授予选择权限,以便用户 B 可以将用户 A 的表上的选择权限授予其他人。如果可能的话,这听起来不是一个好主意,也不是视图工作所必需的。

    【讨论】:

    • SYSTEM 也可以申请授权,您不必以 userA 身份登录。这样你就不需要脚本中的密码了。
    • 没错,我想我假设想要使用 userA 凭据意味着他们没有 DBA 权限。我读它是因为他们是 userB,但碰巧也知道 userA。任意假设有问题是多么不寻常......
    【解决方案4】:

    让用户 A 将他的表上的选择授予 B 并包含“授予选项”。

    作为用户 A:

    GRANT select ON table TO user_b WITH GRANT OPTION;
    

    让用户 B 将其视图的选择权授予用户 A,并包含“授予选项”。

    作为用户 B:

    GRANT select ON view TO user_a WITH GRANT OPTION;
    

    作为用户 A:

    GRANT select on user_b.view TO user_c;
    

    这允许用户 A 将此授权传递给其他用户。

    【讨论】:

    • B 只能在 A 已经在其表上授予 WITH GRANT OPTION 的情况下将视图上的选择授予 A。此外,A 不必在视图上进行选择以便 C 在视图上进行选择。
    • 我在 A 到 B 的表上添加了 WITH GRANT OPTION。我认为 A 需要在视图上选择才能将此授权传递给 C(如问题中所述,“有没有办法使用模式 A 的用户名/密码执行此操作。"
    • 嗯,这行得通。正如 OMG Ponies 指出的那样,这个问题是矛盾的,在用户 B 中指定了一个使用用户 B 的用户名/密码的脚本。
    猜你喜欢
    • 2015-02-05
    • 1970-01-01
    • 2011-03-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多