0

CONNECT私は役割を通じてユーザーに付与しようとしました：

CREATE ROLE my_role IDENTIFIED BY "passwd";
GRANT CONNECT TO my_role;

CREATE USER my_user IDENTIFIED BY "passwd";
GRANT my_role TO my_user;

これを10gで試してみると正常に動作しますが、11gではログインが拒否されます。

ORA-01045:user MY_USER lacks CREATE SESSION privilege; logon denied

役割を付与CREATE SESSIONしても違いはありません。
ユーザーに直接許可CONNECT（またはCREATE SESSION）した後にのみログインできます。

Oracleはこの動作を変更しましたか、それとも私は何か間違ったことをしていますか？

4

3 に答える 3

6

10gのセキュリティ「機能」で逃げたのではないかと思います。11gのSQLリファレンスおよびセキュリティガイドを読んだ方法は、パスワードが有効なロールでは、SET ROLE my_role IDENTIFIED BY passwdそのロールによって付与された権限が有効になる前に、を使用する必要があることを示しています。

あなたがCREATE SESSIONその役割を得るまであなたはできません、そしてあなたが発行するまであなたはその役割を持つことができませんSET ROLE。

キャッチ22。

于 2010-02-17T16:30:40.773 に答える
2

Oracleナレッジベース[ID745407.1]で説明されています。

のDEFAULT句：

ユーザーのデフォルトの役割を変更します; ログオン時にユーザーにデフォルトで付与されるロールを指定します。この句には、GRANTステートメントを使用してユーザーに直接付与されたロール、またはCREATEROLE権限を使用してユーザーが作成したロールのみを含めることができます。DEFAULTROLE句を使用して以下を有効にすることはできません。

  1. ユーザーに付与されていない役割

  2. 他の役割を通じて付与された役割

  3. 外部サービス（オペレーティングシステムなど）またはOracleInternetDirectoryによって管理される役割

  4. パスワードで認証されたロール。

  5. 安全なアプリケーションロールとして実装されるロール。

パスワード認証されたロールの場合、この変更はバージョン10.2.0.5および11.1.0.7で導入されました。安全なアプリケーションロールのために、変更はOracleリリース10.2.0.4および11.1.0.7で導入されました。これらの変更は、将来のすべてのリリースに適用されます。上記の制限は、将来のドキュメントで導入される予定です。

次の結果のスクリプトを実行することで、パスワードが有効な役割を標準の役割に簡単に変えることができます。

'alter role' ||role||'を選択します 特定不能;' password_required ='YES'であり、ロールが存在しないdba_rolesから（dba_application_rolesからロールを選択）。

于 2011-12-15T11:34:54.750 に答える
1

パスワードで保護されているデフォルトのロール（デフォルトとしてユーザーに付与）のアクティブ化は、Oracle 10gバージョン10.2.0.5で変更されました（少なくとも私たちのコピーでは）。リリース10.2.0.5では、パスワードで保護された役割はデフォルトでアクティブ化されなくなりました。適切なパスワードで具体的にオンにする必要がありました。

これは、私たちが知る限り文書化されていませんでした。しかし、システムが10.2.0.4から10.2.0.5にアップグレードされたとき、この変更によりいくつかのシステムが破損し、デフォルトの役割をアクティブ化するメカニズムがない機能アカウントに対して、保護されていない並列の役割を作成する必要がありました。old_role whishのコピーはパスワードで保護されていたため、基本的にパスワードなしでold_role_batchを作成しました。

于 2011-05-11T19:09:41.537 に答える