Firebird Documentation IndexFirebird 2.5 リリースノート → 管理機能
Firebird Home Firebird Home Prev: RemoteFileOpenAbilityFirebird Documentation IndexUp: Firebird 2.5 リリースノートNext: トレースと監査サービス

管理機能

Table of Contents

新しいシステムロールRDB$ADMIN
トレースと監査サービス
モニタリングの改善

Firebirdの管理機能にいくつか改善が施されました。多くの皆さんがこれを歓迎するでしょう。

新しいシステムロールRDB$ADMIN

Alex Peshkov

新たな定義済みシステムロールRDB$ADMINが追加され、SYSDBA権限を他のユーザーに譲渡できるようになりました。どのユーザーでも、特定のデータベースでこのロールが付与された場合、その指定されたロールRDB$ADMINを持つデータベースにアタッチする際にSYSDBAと同様の権限を手にします。

これを割り当てるには、SYSDBAはそのデータベースにログインしている必要がありますが、ロールRDB$ADMINをユーザーに付与する方法は、他のロールをユーザーに付与する仕方と同様です。このロールを付与されたユーザーが、そのデータベースでの“スーパーユーザー”権限にアクセスするためには、ログイン時にこれを明記する必要があります。

Important

ユーザーがアタッチする際に、ユーザー・データベース・ロールが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権限を得る方法が変更されました。

Windowsの“信頼されたユーザー認証”が、デフォルトでは利用できなくなりました!

デフォルトでは、firebird.confAuthenticationパラメータはnativeに設定されています。“信頼されたユーザー認証”を有効にするには、trustedmixedへと明示的に設定しなければなりません。

WindowsのAdministrators向けのグローバル管理者権限

信頼されたユーザー認証”が設定されているFirebirdサーバーで、信頼されたドメイン管理者がSYSDBAアクセス権限を得るには、ドメイン管理者はロールRDB$ADMINに属している必要があります。通常のユーザー向けとして上で解説した手動による方法を使い、データベースごとにそれぞれ特定の管理者にロールRDB$ADMINを付与します。

しかし、SYSDBAがサーバーを設定することで、Windows管理者が任意のデータベースにログインする時にロールRDB$ADMINが自動的にマッピングされるようにする方法があり、これによって、POSIXシステムでroot権限を持つユーザーがSYSDBA権限と関連付けられているのと同様の状況にすることができます。新しいALTER ROLE文はこの目的のため(だけ)に用いられます。

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;
            
サービスAPIタグアイテム

同様の効果はサービスAPIに用意された二つのタグアイテムでサポートされます:自動マッピングを有効にするisc_action_svc_set_mappingとそれを無効にするisc_action_svc_drop_mappingです。

これらのタグはfbsvcmgrユーティリティでサポートされています。

ユーザー管理用に拡大するRDB$ADMINの範囲

新しいDDLコマンドALTER USERにより、“通常の”ユーザー(普通のFirebirdユーザーやPOSIX上での非rootユーザー、または“信頼されたユーザー認証”が有効になっているWindowsシステム上で信頼されたユーザー)が、任意のデータベースにログインしている間、パスワードおよび/または個人名要素を変更できるようになります。スーパーユーザーは、同じコマンドを使ってユーザーの作成と削除を行うこともできます。この新しいコマンドの詳細については、データ定義言語の章のCREATE/ALTER/DROP USERの項を参照して下さい。

security2.fdbはODS 11.2データベースとして(アップグレードが必要な場合もあります)作成されるので、ここにも定義済みロールRDB$ADMINがあります。どのユーザーも—SYSDBAでさえも—セキュリティ・データベースにログインすることができないため、SYSDBAまたはスーパーユーザーが、ユーザーの作成・削除する権限が必要な通常のユーザーに対してsecurity2.fdbのロールRDB$ADMINを適用できるという代替手段が提供されています。これには三つの方法があり、それぞれ同等の効果を持ちます。

  1. 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;
                

  2. gsecユーティリティに-adminスイッチを付けて使用します。このスイッチは引数を一つ取ります:YESの場合、ロールRDB$ADMINがユーザーに適用されます。NOの場合、このロールは取り消されます。詳細は、ユーティリティの章のgsecの節のロールRDB$ADMINを通常のユーザーに付与するの項を参照して下さい。

  3. SPBパラメータisc_spb_sec_adminを使います。これはsecurity2.fdbで通常のユーザーにロールRDB$ADMINをSPB接続を介して割り当てる実装です。詳細については、Firebird APIとODSの変更の章のParameter isc_spb_sec_adminの項に記載されています。

    fbsvmgrユーティリティもこのパラメータの使用をサポートしています。

Tip

Firebird 2.5では、サーバーに複数のセキュリティ・データベースを作成することはできません。バージョン3.0以降は、データベースごとに個別のセキュリティ・データベースを持てるようになる予定です。現状では、サーバー上の任意のデータベース(employee.fdbも含め)に接続するごとに唯一のsecurity2.fdbが更新されることになります。

将来的に、これらのリクエストは影響を受ける各セキュリティ・データベースに対応するデータベースから送信することが必須となります。

Prev: RemoteFileOpenAbilityFirebird Documentation IndexUp: Firebird 2.5 リリースノートNext: トレースと監査サービス
Firebird Documentation IndexFirebird 2.5 リリースノート → 管理機能