【问题标题】:Preventing a user from dropping its' own trigger防止用户放弃自己的触发器
【发布时间】:2012-04-20 21:14:53
【问题描述】:

我在 Oracle DB 中创建了一个只读用户 A。 (谁可以访问架构 X 但不能更改任何内容)然后我被要求授予用户 A 在架构 X 上创建表的权限。

但据我所知,我可以将create any table 权限授予用户A 或create table 权限。其中一个是在他/她自己的架构上创建表,另一个是在所有架构上创建表,这不应该是首选。

所以我给用户 A create any table 权限,然后创建了一个触发器,阻止用户 A 在 X 以外的模式上创建表。

然而, 我需要将触发器创建为用户 A,现在用户 A 可以轻松删除该触发器,因为 A 是所有者。 有什么办法可以防止用户 A 放弃触发器,即使他/她是所有者?

据我所知,用户 A 不需要删除任何触发器或管理数据库触发器权限,因为触发器已经是他/她自己的了。

有什么解决方法吗?或者我应该寻找一种替代方法来授予对其他模式的创建表权限。

提前谢谢你。

【问题讨论】:

    标签: oracle


    【解决方案1】:

    不,没有办法阻止用户删除它拥有的对象。

    也没有办法直接允许用户 A 在用户 X 的架构中创建对象,除非您开始授予“ANY”权限。

    一种可能的解决方法是在用户 X 的架构中创建一个存储过程,该存储过程将在用户 X 的架构中创建对象(立即执行)并将所述存储过程的 EXECUTE 权限授予用户 A。

    因此,通过这种方式,用户 A 可以执行以下操作:

    exec create_in_x_schema('create table blah(a number)');
    

    并且该过程只会对传入的字符串执行立即执行。

    A procedure that looks something like:
    create or replace procedure create_in_x_schema(doit varchar2)
    begin
      execute immediate doit;
    end;
    /
    

    应该这样做。

    (代码未经测试,但应该能给你一些想法。)

    希望对您有所帮助。

    【讨论】:

    • 当然,该过程应确保“doit”是您允许用户执行的操作。所以使用 DBMS_ASSERT 来检查 SQL。并添加代码以确认它是您允许的选项之一,例如“创建表”。否则,X 能做的任何事,A 都能做。
    • 绝对正确。我上面发布的代码可能存在很大的安全风险。这是严格的概念证明。
    猜你喜欢
    • 2011-10-11
    • 2017-01-19
    • 2013-04-09
    • 1970-01-01
    • 1970-01-01
    • 2017-09-27
    • 2017-04-26
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多