web-dev-qa-db-ja.com

「GRANT SELECT ... TO Role;」を実行する理由RoleのメンバーにSELECTを許可しませんか？

Oracle 11gデータベースで次のシナリオを検討してください。

ユーザーADMINは以下を実行します。

CREATE USER Alice IDENTIFIED BY pwdalice;

GRANT CREATE SESSION TO Alice;

CREATE ROLE Viewer IDENTIFIED BY pwdviewer;

GRANT Viewer TO Alice;

GRANT SELECT ON Table_1 TO Viewer;

次に、アリスはデータベースに「アリス」としてログインし、次のコマンドを実行します。

SELECT * FROM Table_1;

アリスは次のエラーを受け取ります：

SELECT * FROM Table_1
              *
ERROR at line 1:
ORA-00942: table or view does not exist

ロールに特権を付与すると、そのメンバーユーザーがそれらの特権を取得できるようになると思いました。ただし、このシナリオはそうではないことを示しています。ここで何が欠けていますか？ロールを使用してSELECTをアリスに付与するにはどうすればよいですか？

更新：

役立つ回答に続き、3つの修正を試みましたが成功しませんでした

1）完全修飾テーブル名を使用する

SELECT * FROM Table_1;コマンドにスキーマ名を含めることができませんでした。ただし、以下に示すようにスキーマ名を追加した後でも、エラーが発生します。

アリスは実行します：

SELECT * FROM ADMIN.Table_1;

エラーを取得します。

SELECT * FROM ADMIN.Table_1
                     *
ERROR at line 1:
ORA-00942: table or view does not exist

2）完全修飾テーブル名の同義語を使用する

残念ながら、これでも問題は解決されないようです。

アリスは以下を実行します。

CREATE SYNONYM Syn_Table_1 FOR ADMIN.Table_1;
CREATE SYNONYM Syn_Table_1 FOR ADMIN.Table_1
*
ERROR at line 1:
ORA-01031: insufficient privileges

3）セッションの変更

ALTER SESSION SET current_schema = ADMIN;

Session altered.

SELECT * FROM Table_1;

SELECT * FROM Table_1
              *
ERROR at line 1:
ORA-00942: table or view does not exist
oraclerolepermissions
1
Dilini

正しいスキーマにいることを確認することに加えて、これを試してください。
Aliceとしてログインしたら、次の操作を行います：SET ROLE Viewer IDENTIFIED BY pwdviewer;

詳しくは こちら をご覧ください

2
r.m

作成したロールはパスワードで保護されています。したがって、aliceがログインしたとき、デフォルトでは有効になっていません。

2
user72700

Aliceはテーブルを所有していないため、テーブルの完全修飾名を使用する必要があります。

たとえば、テーブルがTABLE_1_OWNERによって所有されている場合：

SELECT * FROM TABLE_1_OWNER.TABLE_1;

`アリスは自分のスキーマに、テーブルを指すシノニムを作成することもできるため、名前を完全に修飾する必要がなくなります。

CREATE SYNONYM TABLE_1 FOR TABLE_1_OWNER.TABLE_1;
1
Philᵀᴹ

問題は名前解決の問題であり、特権ではありません。

テーブルtable_1は、Aliceスキーマ以外のスキーマに存在します。 Aliceがクエリを実行するとき

SELECT * 
  FROM table_1

Oracleは現在のスキーマを調べて、table_1という名前のオブジェクトがあるかどうかを確認します。そのようなオブジェクトがないため、エラーがスローされます。

テーブル名を修飾することで、オブジェクトがどのスキーマにあるかをOracleに通知することで、これを修正できます。

SELECT * 
  FROM <<owner of table_1>>.table_1

または、マッピングを提供するシノニム（パブリックまたはプライベート）を作成できます。たとえば、アリスとして、プライベートシノニムを作成できます

CREATE SYNONYM table_1
   FOR <<owner of table_1>>.table_1

それをしたら、アリスは簡単にできます

SELECT * 
  FROM table_1

アリスのスキーマにtable_1（実際のテーブルのプライベートシノニム）という名前のオブジェクトがあるためです。

3番目のオプションは、セッションの現在のスキーマを変更することです。繰り返しますが、アリスとして、実行すると

ALTER SESSION SET current_schema = <<owner of table_1>>;

その後、実行できるようになります

SELECT * 
  FROM table_1

ただし、それを行う場合、テーブル名がAliceスキーマに存在する場合は、完全に修飾する必要があります（もちろん、current_schemaを再度変更しない限り）。

1
Justin Cave

シノニムとロールに付与された特権のベストプラクティスアプローチを適用した後もこの問題が発生する場合は、権限受領者のユーザーアカウントですべてのロールが有効になっていることを確認してください：ALTER USER DEFAULT ROLE ALL

1
Tito

さらに、ロールを介した付与を許可するには、ユーザーとの新しい接続を作成する必要があることがわかります。 「単純な」再接続は機能しません。

0
Sébastien Tromme

この問題を解決していない場合は、まず役割を作成し、対応する権限を追加してください。次に、ユーザーを作成してロールを割り当てます。

この順序で、うまくいくと思います。それは私にとってはうまくいき、あなたが経験していたのと同じ問題を抱えていました。

0
Revi