この章では、Postgres とオペレーティング・システム間のやりとりについての概要を説明する。特にこの章では、Unix コマンドとして実行される Postgres サポートプログラムについて記述する。
以下の文書ではサイトという言葉を、Postgres がインストールされたホストマシンの意味で使用することがある。1 つのホスト上に 1 つ以上の Postgres データベースをインストールすることができる以上、この言葉は、インストールされた Postgres バイナリおよびデータベースのある特定のセットを、より正確に意味することになる。
Postgres のスーパーユーザは、Postgres のバイナリとデータベースを所有する、 "postgres" という名前のユーザである。データベースのスーパーユーザに対してはすべての保護メカニズムが無視され、いかなるデータも独占的にアクセスできる。これに加えて Postgres のスーパーユーザは、一般的に全ユーザが使用できるわけではないいくつかのサポートプログラムを実行することができる。Postgres のスーパーユーザは、Unix のスーパーユーザrootであってはならず、また、セキュリティ的な理由により非 0 のユーザ ID を持つべきである。
データベース管理者または DBA は、そのサイトに際してセキュリティ・ポリシーを確保するために、Postgres のインストールに責任を負う人である。
postmasterは、Postgres システムへの要求に際しての情報センターとして動作するプロセスである。フロントエンド・アプリケーションは、すべてのシステムエラーやバックエンドプロセスとの通信を追跡するpostmasterに接続する。postmasterは、その振る舞いを調整するために、いくつかのコマンドライン引数を取ることができる。しかしながら、複数のサイトやデフォルトではないサイトを運用したい場合にのみ、引数を指定すれば良い。詳細はpostmaster(1) を参照のこと。
Postgres バックエンド(postgres と呼ばれる、実際に動作可能なプログラム)は、Postgresスーパーユーザにより(データベース名を引数として)ユーザシェルから直接起動される。しかしながらこれを行うと、、サイト毎の postmaster に関連付けられている共有バッファプールやロックテーブルなどがバイパスされてしまう。このため、マルチユーザ・モードでは直接実行は推奨されていない。
ファイル名の最初にある ".../" は、Postgres スーパーユーザのホームディレクトリへのパスを示している。 ("[" と "]") の中にあるものはオプションである。 ("{" と "}") の中にあるものは 0 回以上繰り返される。 ("(" と ")" ) の中にあるものは グループのブール表現として使用される。 "|" はブール演算子の OR である。
Unix シェルから直接実行されるすべての Postgres コマンドは、".../bin" から検索される。このディレクトリをあなたの検索パスに追加してやれば、簡単にコマンドを実行できるようになる。
各サイトにはシステムカタログ群がある。これらには、有効な Postgresの各ユーザのインスタンスが入っている ("pg_user") クラスが含まれる。このインスタンスでは、Postgres のスーパーユーザとして振る舞うことができるか、データベースを生成／削除することができるか、システムカタログを更新することができるかなどの、Postgres における権限のセットが指定されている。このクラスに適切なインスタンスがインストールされて初めて、Unix のユーザは Postgres に対して何かの操作を行うことができるようになる。システムカタログ上における詳細情報を得るには、適切なクラスにおいて問い合わせを発行してほしい。
認証は、バックエンドサーバとpostmasterが、データにアクセスしようとしているユーザが本当に要求する権限を持っているかどうかを確認するための処理である。Postgres を呼び出すすべてのユーザについて、彼らがその操作を行う権限を確認するのに、"pg_user" クラスの内容に対してのチェックが行われる。しかしながら、ユーザ識別チェックはいろいろな方法で実行される。.SS ユーザシェルからユーザシェルから起動されたバックエンドサーバは、ユーザ"postgres" のユーザ ID にsetuid(3) する前に、ユーザの(実効)ユーザ ID に注目する。実効ユーザ ID は、アクセス制御チェックの基準として使われるものである。それ以外の認証は行われない。.SS ネットワークからネットワークに開放するように Postgres システムが構築されていれば、postmasterプロセスのインターネット TCP ポートへのアクセスは誰にでも行える。DBA は、どのホストが接続を確立でき、またどのデータベースに接続するかに応じて、どの認証システムを使用すべきかを PGDATAディレクトリにある pg_hba.conf ファイルに設定する。使用可能なconf(5) を参照のこと。もちろんホストベースの認証は、Unix では絶対安全なものではない。確信犯である侵入者は、オリジナルのホストに成りすますことも可能なのだから。これらのセキュリティの問題点は Postgres がカバーできる範囲を超えている。
Postgres ではユーザに対して、他のユーザへ提供された彼らのデータへのアクセスを制限するためのメカニズムを提供している。.SS データベースのスーパーユーザデータベースのスーパーユーザ( "pg_user.usesuper" セットを持つユーザ)は、「ユーザが "pg_user.usecatupd" セットを持っていない場合は、手作業によるシステムカタログの更新は許されない」、および「システムカタログの破壊(またはそれらスキームの改竄)は許されない」という 2 つの例外により、以下に示すすべてのアクセス制御を黙ってバイパスする。.SS アクセス特権revoke(l) により、クラスの読み書きおよびルールの設定を制限するためのアクセス特権を使うことができる。.SS クラスの削除とスキーマの改竄alter ,drop table ,およびdrop index ,のように、存在するクラスの構造を破壊したり改竄したりするコマンドは、その所有するクラスに対してのみ行うことができる。上で述べたように、これらの操作をシステムカタログに対して許可 してはならない。
ユーザは、関数とルールにより、他のユーザが何も知らないうちにバックエンドサーバに対してコードを追加することができる。このためこの双方のメカニズムにより、ユーザは何のとがめもなく トロイの木馬 などをしかけることができる。唯一現実的な保護策としては、関数とルールを定義する(すなわち SQL フィールドにリレーションを張る)ことができるユーザを厳しく制御することである。 "pg_class", "pg_user" および "pg_group" に対して変更の追跡をしたり、警告を発するようにすることも 推奨される。.SS 関数SQL を除く任意の言語で書かれた関数は、バックエンドプロセスの内部において、ユーザ "postgres" の権限の元で(バックエンドサーバは、"postgres") にセットされた実ユーザ ID および実効ユーザ ID で動作する)で実行される。ユーザは、信頼される関数の内部からサーバの内部データ構造体を変更することも可能である。このため、関数など多くの事柄の間でいかなるシステムのアクセス制御をも迂回することができる。これは、ユーザ定義の C 関数から引きずっている問題である。.SS ルールSQL 関数のように、ルールは常にその ID と、バックエンドサーバを起動したユーザの権限の元で実行される。
abort(l) declare(l) large_objects(3)
alter_table(l) delete(l) libpq(3)
alter_user(l) destroydb(1) listen(l)
begin(l) destroyuser(1) load(l)
bki(5) drop(l) lock(l)
catalogs(3) drop_aggregate(l) move(l)
cleardbdir(1) drop_database(l) notify(l)
close(l) drop_function(l) oracle_compat(3)
cluster(l) drop_index(l) page(5)
commit(l) drop_language(l) pg_dump(1)
copy(l) drop_operator(l) pg_dumpall(1)
create_aggregate(l) drop_rule(l) pg_hba(conf(5)
create_database(l) drop_sequence(l) pg_passwd(1)
create_function(l) drop_table(l) pgbuiltin(3)
create_index(l) drop_trigger(l) pgintro(1)
create_language(l) drop_type(l) postgres(1)
create_operator(l) drop_user(l) postmaster(1)
create_rule(l) drop_view(l) psql(1)
create_sequence(l) ecpg(1) reset(l)
create_table(l) end(l) revoke(l)
create_trigger(l) explain(l) rollback(l)
create_type(l) fetch(l) select(l)
create_user(l) grant(l) set(l)
create_version(l) initdb(1) show(l)
create_view(l) initlocation(1) sql(l)
createdb(1) insert(l) update(l)
createuser(1) ipcclean(1) vacuum(l)
(ユーザ定義関数の中で、ユーザを暗号化データに触らせないようなしくみはないが、) Postgres の内部で暗号化データを明示的にサポートするための計画はない。また、暗号化されたネットワーク接続を明示的にサポートしたり、フロントエンド／バックエンドプロトコルを全面的に書き直したりするような計画もない。
ユーザ名、グループ名その他関連するシステム ID (すなわち"pg_user.usesysid" の中身)は、データベースを通してユニークであるとみなされる。この原則が守られていない場合は、予期しない結果となることがある。
.SS 可用性Kerberos認証システムは、Postgres とともに配布されてはおらず、カリフォルニア大学バークレイ校 (UCB) から取ってこれると言うわけでもない。Kerberosのいくつかのバージョンは、一般的にはオペレーティングシステムのベンダーからオプション・ソフトウェアとして供給されるものである。加えて、ソースコードの配布は MIT Project Athena を通してATHENA-DIST.MIT.EDU(18.71.0.38) から anonymous FTP で取得できるかもしれない。(ベンダーが移植したものの中には、故意に機能を限定していたり MIT バージョンとは互換性がないようなものも見受けられるので、もしあなたがベンダー提供のものを持っていたとしても、MITバージョンのものが欲しいと思うかもしれない。) 米国およびカナダ以外に住むユーザについては、Kerberos内の実際の暗号化コードは米国政府の輸出法規により制限されているので注意してほしい。
これ以上の問い合わせについては、あなたのベンダーかまたは、MITProject Athena ("info-kerberos@ATHENA.MIT.EDU") に対して行ってほしい。また、FAQL (頻繁に行われる質問と回答のリスト)は、定期的にKerberosメーリングリスト "kerberos@ATHENA.MIT.EDU"( "kerberos-request@ATHENA.MIT.EDU" に subscribe というメールを送る) や USENET ニューズグループ"comp.protocols.kerberos" に投稿されている。.SS インストールKerberosのインストール自体は、Kerberos Installation Notesに詳細に述べられている。サーバ・キーファイル(srvtabまたはkeytab)をどうにかしてユーザ "postgres" から読めるようにしておくことに注意すること。
ファイル ".../src/Makefile.global" にある変数 KRBVERS を適切な値に設定すれば、Postgres とそのクライアントを、MITKerberosプロトコルのバージョン 4 または 5 のいずれかで使うようにコンパイルすることができる。また、関連ライブラリ、ヘッダファイル、所有するサーバ・キーファイルを、Postgres が期待する場所に置いておくことも必要である。
コンパイルが正常に終了したら、Postgres をKerberosサービスとして登録しなければならない。サービス登録に関する詳細は、Kerberos Operations Notesおよび関連マニュアルを参照のこと。初期インストールの後は、すべての方法で Postgres が通常のKerberosサービスとして動作していなければならない。認証機能を使用する際の詳細については、postmaster(1) とpsql(1) マニュアルページを参照のこと。
Kerberosバージョン 5 においては、ユーザおよびサービスの命名に関して以下のことが前提となっている：(1) ユーザの公式名(anames)は、最初の構成要素として実際の Unix/Postgres ユーザ名を含むとみなされる。(2) Postgres サービスは、バージョン 4 において正式に認められたサービス名とホスト名という 2 つの構成要素を持っていると見なされる(すなわちすべてのドメイン・サフィックスは取り除かれる)。
user example: frew@S2K.ORG
user example: aoki/HOST=miyu.S2K.Berkeley.EDU@S2K.ORG
host example: postgres_dbms/ucbvax@S2K.ORG
MIT によるバージョン 5 の製品リリース後には、いずれバージョン 4のサポートはなくなる。
堀田 倫英 <hotta@net-newbie.com>