| Firebird Documentation Index → Firebird 2.5 リリースノート → 管理機能 |
|
|
|
Table of Contents
Firebirdの管理機能にいくつか改善が施されました。多くの皆さんがこれを歓迎するでしょう。
新たな定義済みシステムロールRDB$ADMINが追加され、SYSDBA権限を他のユーザーに譲渡できるようになりました。どのユーザーでも、特定のデータベースでこのロールが付与された場合、その指定されたロールRDB$ADMINを持つデータベースにアタッチする際にSYSDBAと同様の権限を手にします。
これを割り当てるには、SYSDBAはそのデータベースにログインしている必要がありますが、ロールRDB$ADMINをユーザーに付与する方法は、他のロールをユーザーに付与する仕方と同様です。このロールを付与されたユーザーが、そのデータベースでの“スーパーユーザー”権限にアクセスするためには、ログイン時にこれを明記する必要があります。
ユーザーがアタッチする際に、ユーザー・データベース・ロールがDPB（接続パラメータ）に渡されている場合、これをRDB$ADMINと置き換えることはできません。つまりこの場合、SYSDBA権限を得ることはできません。
次に挙げる例では、SYSDBA権限がユーザー（User1とAdmins\ADMINS）に譲渡されています。このうち二番目のユーザーは、“信頼された認証”を介してアクセスが有効とされたWindowsシステムユーザーとして典型的なものです：
GRANT RDB$ADMIN TO User1;
GRANT RDB$ADMIN TO "Admins\ADMINS";
RDB$ADMINロールが割り当てられている場合でも通常のユーザーがSYSDBAになるわけではないということは理解しておくべきです。正確には、あるデータベースでユーザーにこのロールが付与されている時、そのユーザーはデータベース内のオブジェクトに対してSYSDBAと同等の権限を与えられている、ということです。
同じユーザーに複数のデータベースでのスーパーユーザー権限が必要な場合、そのユーザーに対するロールRDB$ADMINは、それぞれのデータベースについて明示的に付与されなければなりません。
一つのデータベースに対して複数のユーザーにスーパーユーザー権限を持たせたい場合、それぞれのユーザーにロールRDB$ADMINを付与する必要があります。
ユーザーがあるデータベースのロールRDB$ADMINに属している場合、これを他のユーザーに付与することができます。
WITH ADMIN OPTION（このロールを他のユーザーに付与する権限のために）や、WITH GRANT OPTION（オブジェクトの所有者であることなしに他のユーザーにそれらのオブジェクトに対するパーミッションを付与する権限のために）を指定する必要はありません。ADMINやGRANTオプションは暗に含まれています。
POSIXホストではrootユーザーが常にSYSDBA権限を持っていますが、このことは、Firebird 2.1まで、Windowsのドメイン管理者には当てはまりませんでした。バージョン2.1で設定パラメータAuthenticationが導入されたことにより、Windowsドメイン管理者としてログインしているユーザーは、“信頼されたユーザー認証”を通して、自動的にSYSDBA権限でサーバーにアクセスできるようになりました。POSIX版ではこの仕組みに変更はありませんが、Windows版では、ロールRDB$ADMINの導入により、WindowsのAdministratorsがSYSDBA権限を得る方法が変更されました。
デフォルトでは、firebird.confのAuthenticationパラメータはnativeに設定されています。“信頼されたユーザー認証”を有効にするには、trustedかmixedへと明示的に設定しなければなりません。
“信頼されたユーザー認証”が設定されているFirebirdサーバーで、信頼されたドメイン管理者がSYSDBAアクセス権限を得るには、ドメイン管理者はロールRDB$ADMINに属している必要があります。通常のユーザー向けとして上で解説した手動による方法を使い、データベースごとにそれぞれ特定の管理者にロールRDB$ADMINを付与します。
しかし、SYSDBAがサーバーを設定することで、Windows管理者が任意のデータベースにログインする時にロールRDB$ADMINが自動的にマッピングされるようにする方法があり、これによって、POSIXシステムでroot権限を持つユーザーがSYSDBA権限と関連付けられているのと同様の状況にすることができます。新しいALTER ROLE文はこの目的のため（だけ）に用いられます。
“信頼されたユーザー認証”が有効になっているWindowsサーバーで、ロールRDB$ADMINを管理者に自動的にマッピングするようにデータベースを設定するには、SYSDBAは、任意のデータベースにログインし、以下のSQL文を発行します：
ALTER ROLE RDB$ADMIN
SET AUTO ADMIN MAPPING;
デフォルト設定に戻して管理者が自動的にはSYSDBA権限を得ないようにするには、次のSQL文を発行します：
ALTER ROLE RDB$ADMIN
DROP AUTO ADMIN MAPPING;
新しいDDLコマンドALTER USERにより、“通常の”ユーザー（普通のFirebirdユーザーやPOSIX上での非rootユーザー、または“信頼されたユーザー認証”が有効になっているWindowsシステム上で信頼されたユーザー）が、任意のデータベースにログインしている間、パスワードおよび／または個人名要素を変更できるようになります。スーパーユーザーは、同じコマンドを使ってユーザーの作成と削除を行うこともできます。この新しいコマンドの詳細については、データ定義言語の章のCREATE/ALTER/DROP USERの項を参照して下さい。
security2.fdbはODS 11.2データベースとして（アップグレードが必要な場合もあります）作成されるので、ここにも定義済みロールRDB$ADMINがあります。どのユーザーも—SYSDBAでさえも—セキュリティ・データベースにログインすることができないため、SYSDBAまたはスーパーユーザーが、ユーザーの作成・削除する権限が必要な通常のユーザーに対してsecurity2.fdbのロールRDB$ADMINを適用できるという代替手段が提供されています。これには三つの方法があり、それぞれ同等の効果を持ちます。
CREATE USERまたはALTER USER文でオプションパラメータGRANT ADMIN ROLEを使う。
この場合のGRANT ADMIN ROLEやREVOKE ADMIN ROLEがGRANT／REVOKE文ではなく、CREATE USERやALTER USER文に対する3キーワードパラメータであることに注意して下さい。'ADMIN'という名のシステムロールは存在しません。
データベースのロールRDB$ADMINを手にしている任意のユーザーは暗黙のうちに拡張権限WITH ADMIN OPTIONとWITH GRANT OPTIONを手にしています。
例
セキュリティ・データベースでユーザーalexにロールRDB$ADMINを付与する場合：
ALTER USER alex GRANT ADMIN ROLE;
セキュリティ・データベースでユーザーalexからロールRDB$ADMINを取り消す場合：
ALTER USER alex REVOKE ADMIN ROLE;
すべてのデータベースでユーザーalexを削除しその権限も削除する場合：
DROP USER alex;
gsecユーティリティに-adminスイッチを付けて使用します。このスイッチは引数を一つ取ります：YESの場合、ロールRDB$ADMINがユーザーに適用されます。NOの場合、このロールは取り消されます。詳細は、ユーティリティの章のgsecの節のロールRDB$ADMINを通常のユーザーに付与するの項を参照して下さい。
SPBパラメータisc_spb_sec_adminを使います。これはsecurity2.fdbで通常のユーザーにロールRDB$ADMINをSPB接続を介して割り当てる実装です。詳細については、Firebird APIとODSの変更の章のParameter isc_spb_sec_adminの項に記載されています。
fbsvmgrユーティリティもこのパラメータの使用をサポートしています。
Firebird 2.5では、サーバーに複数のセキュリティ・データベースを作成することはできません。バージョン3.0以降は、データベースごとに個別のセキュリティ・データベースを持てるようになる予定です。現状では、サーバー上の任意のデータベース（employee.fdbも含め）に接続するごとに唯一のsecurity2.fdbが更新されることになります。
将来的に、これらのリクエストは影響を受ける各セキュリティ・データベースに対応するデータベースから送信することが必須となります。
|
| Firebird Documentation Index → Firebird 2.5 リリースノート → 管理機能 |