0

ユーザー B のスキーマのテーブルを更新するオブジェクトがユーザー A にあります。パッケージが実行されると、ユーザー B のログインを使用して Oracle で実行されます。

ユーザー A には、ユーザー B のスキーマ内のテーブルを更新する権限がありません。ユーザー A のスキーマでパッケージをコンパイルしようとすると、特権が不十分というエラー メッセージが表示され、コンパイルが停止します。

ユーザー A にはユーザー B のテーブルを更新する権限がありませんが、ユーザー A のスキーマでオブジェクトをコンパイルする方法はありますか? パッケージが USER B のコンテキストで実行された場合、パッケージはテーブルを正しく更新しますか?

パッケージを USER B のスキーマに入れたくありません。

4

1 に答える 1

2

あなたはできる。しかし、それはおそらく最善の方法ではありません。パッケージは、実行者権限パッケージとして宣言する必要があります。また、UPDATEステートメントは動的 SQL を使用する必要があります。

でテーブルを作成しますB

SQL> create table b.foo( col1 number );

Table created.

SQL> insert into b.foo values( 1 );

1 row created.

SQL> commit;

Commit complete.

でパッケージを作成しますA。パッケージが宣言されていることに注意してください。これは、パッケージがauthid current_user定義ユーザーではなく、呼び出しユーザーの権限に依存していることを意味します。またA、テーブルが表示されないため、動的 SQL を使用して、構文チェックが実行時に延期されるようにします。

SQL> create package update_foo
  2    authid current_user
  3  as
  4    procedure set_val( p_new_val in number );
  5  end;
  6  /

Package created.

SQL> ed
Wrote file afiedt.buf

  1  create or replace package body update_foo
  2  as
  3    procedure set_val( p_new_val in number )
  4    as
  5    begin
  6      execute immediate 'update b.foo set col1 = :new_val'
  7        using p_new_val;
  8    end;
  9* end;
SQL> /

Package body created.

SQL> grant execute on update_foo to b;

Grant succeeded.

これでB、パッケージを実行してデータを変更できます

SQL> exec a.update_foo.set_val( 2 );

PL/SQL procedure successfully completed.

SQL> select * from foo;

      COL1
----------
         2

ただし、一般的に、これは特に賢明なアプローチではありません。一般に、コードをあるスキーマに、オブジェクトを別のスキーマに持つことの全体的なポイントは、義務と責任の分離を提供することです。とにかくテーブルに対してを発行できるユーザーとしてログインする必要がある場合、UPDATEそれを行うためのパッケージを用意してもセキュリティはあまり向上しません。この場合、複雑さが増すだけです。

于 2013-03-13T01:06:38.220 に答える