SQL 構文リファレンス : SET SECURITY
 
このページをシェアする                  
SET SECURITY
SET SECURITY ステートメントを使用すると、Master ユーザーはログオンしているデータベースのセキュリティを有効または無効にできます。
構文
SET SECURITY [USING 認証の種類] = < 'パスワード' | NULL >
備考
セキュリティを設定するには、まず Master としてログオンする必要があります。その後、SET SECURITY ステートメントを使用してパスワードを割り当てることができます。セキュリティで保護されていないデータベースにログオンする場合、Master はパスワードを要求されません。しかし、データベースにセキュリティを設定する場合は、Master ユーザーは割り当てられたパスワードが必要になります。
SET SECURITY は、Master ユーザーのセッションが現在の唯一のデータベース接続である場合のみ発行できます。セキュリティは PSQL Control Center(PCC)から設定することもできます。『PSQL User's Guide』のPSQL エクスプローラーを使用してセキュリティを有効にするにはを参照してください。
認証の種類の文字列は、local_db または domain です。USING 句が含まれていない場合、認証の種類は local_db に設定されます。
認証の種類が domain の場合に、ユーザーに関する SQL スクリプトを実行すると、エラー メッセージ(ステートメントがドメイン認証でサポートされていない)を返します。サポートされないステートメントは、ユーザー関連の ALTER USER、CREATE USER、DROP USER、GRANT や、非 Master ユーザー向けの SET PASSWORD、および REVOKE などです。
パスワード要件については、パスワードの特性を参照してください。
ユーザー権限
オブジェクト(テーブル、ビュー、およびストアド プロシージャなど)のユーザー権限は、SET SECURITY が NULL に設定された後もシステム テーブルに保持されます。次のシナリオを考えてみましょう。
データベース mydbase のセキュリティを有効にし、ユーザー Master がログインします。
Master ユーザーが、ユーザー user1 と user2、およびデータベース mydbase のテーブル t1 を作成します。
user2 に t1 の SELECT 権限を付与します。
mydbase のセキュリティを無効にします。
テーブル t1 を削除します。
テーブル t1 が存在しなくなっても、t1 の権限はシステム テーブル内に残っています(t1 の ID は X$Rights 内にまだあります)。以下について考えてみましょう。
データベース mydbase のセキュリティを再び有効にします。
user1 がデータベースにログインします。
user1 が mydbase の新しいテーブル tbl1 を作成します。tbl1 には、t1 に割り当てられたオブジェクト ID と同じ ID を割り当てることができます。このシナリオでは、t1 と tbl1 に割り当てられるオブジェクト ID を同じにします。
t1 の以前の権限が tbl1 に復元されます。つまり、user1 は、新しいテーブルに対する権限を明示的に付与されていなくても、tbl1 の SELECT 権限を持っているということです。
メモ:オブジェクトに対する権限を削除したい場合は、明示的にその権限を取り消す必要があります。このことは、テーブル、ビュー、およびストアド プロシージャに当てはまります。権限はオブジェクト ID と関連付けられており、データベースは新しいオブジェクトに対し、削除されたオブジェクトのオブジェクト ID を再使用するからです。
次の例では、データベースのセキュリティを有効にし、Master パスワードを "mypasswd" と設定しています。
SET SECURITY = 'mypasswd'
次の例では、データベースのドメイン認証を有効にし、Master パスワードを "123456" と設定しています。
SET SECURITY USING domain = '123456'
============ 
次の例ではセキュリティが無効になります。
SET SECURITY = NULL
関連項目
ALTER USER
CREATE USER
GRANT
REVOKE
SET PASSWORD