Debian JP Project

(for vocal browsers: toc, main)

Google
WWW 全体 www.debian.or.jp 検索


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]


Debian ポリシーマニュアル
Chapter 10 - ファイル


10.1 バイナリファイル

二つのパッケージが、異なった機能を持つ同じ名前のプログラムを インストールする事は許されていません。(二つのパッケージが同 じ機能を提供するが、その実装が異なっている場合には代替 (alternatives) 機能または競合 (Conflicts) 機能を使って処理してください)。これらについては順に メンテナスクリプト, Section 3.9競合するバイナリパッケージ - Conflicts, Section 7.4 を参照ください。 この状況が発生した場合には一方のプログラムが名前を変更しなければなりません。 メンテナは名前が衝突していることを debian-devel メーリングリストに報告して、 どちらのパッケージの名前を変更する方がいいのかの合意を得るようにしてください。 合意が得られない場合には、両方の プログラムが名前を変更しなければなりません。

標準では、パッケージが作成される際には、任意のバイナリはデバッグ情報付きで作成されるべきで、また最適化も行われるべきです。 また、コンパイル時の警告メッセージもできるだけ有効にすべきです。 これは、問題の可能性の有無をビルド時のログを見て判断する移植者の作業を容易にします。 C 言語の場合、上記のことから通常は次のコンパイル時の引数を使うべきです。

     CC = gcc
     CFLAGS = -O2 -g -Wall # warning オプションは変更可です。
     LDFLAGS = # なし
     INSTALL = install -s # (または、debian/tmp で strip をかけてください)

バイナリファイルは標準的には strip をかけておくべきであることに留意してください。 これは install-s フラグか、パッケージツリーを作成する前にいったんプログラムを debian/tmp に移して strip を呼び出すかのどちらかで行ってください。

ビルドツリーでのバイナリはデバッグ情報付きでコンパイルされるべきですが、それでもコンパイラの最適化のためにデバッグはしばしば困難になります。 このため、標準環境変数 DEB_BUILD_OPTIONS のサポートを推奨します (debian/rules および DEB_BUILD_OPTIONS, Section 4.9.1 参照)。 この変数は、パッケージコンパイルとビルドのやり方を変更する幾つかのフラグを含んでいます。

コンパイルオプションに最も適したものを選ぶのはメンテナの判断に任せています。 ある種のバイナリ (たとえば計算量の多いプログラム) にはそれなりのフラグ (-O3 など) の方が実行時の効率が上がるでしょうし、そういうときには自由にそのようなフラグを使ってもかまいません。 的確な判断を行ってください。 漠然とした考えでフラグを設定しないでください。 そうする理由があるときのみに限ってください。 どのコンパイルオプションが適切かについての上流の作者の考えを変更するのは自由です。 なぜならしばしば私たちの環境では適さないものが使われていますので。


10.2 ライブラリ

もし、パッケージが architecture: any となっている場合には、共有ライブラリのコンパイルとリンクフラグには -fPIC を含めなければいけません。 さもなければ、一部のサポートされているアーキテクチャでビルドに失敗します [84] 。この規則の例外は必ず debian-devel@lists.debian.org メーリングリストで議論して、一応の合意を得ておく必要があります。 -fPIC フラグを使わないでコンパイルした理由は必ず README.Debian ファイルに記載をしなければいけませんし、 同時にアーキテクチャを制限するか、必要なアーキテクチャでは -fPIC を用いるようにするケアを行わなければいけません [85]。

言葉を換えれば、もし共有ライブラリとスタティックライブラリの両方をビルドする場合には、各ソース部分 (C 言語では *.c に当たる) は二回コンパイルする必要があります。

ライブラリは、スレッドサポートを行うようビルドすべきで、さらにライブラリのサポートがある場合はスレッドセーフとすべきです。

ビルドツールで強制されているわけではありませんが、共有ライブラリはバイナリ同様、含まれるシンボルを用いる全てのライブラリにリンクするようビルドされていなければいけません。 これにより、symbolsshlibs システムの正しい動作と、全てのライブラリが dlopen() により安全に開くことができることが保証されます。 パッケージメンテナは、共有ライブラリ作成の際に gcc オプション -Wl,-z,defs を使いたいかもしれません。 これらのオプションはビルド時のシンボル解決を強制するため、ライブラリの参照関係の抜けは致命的なビルドエラーとして早いうちに捕まえることが可能です。

インストールされる共有ライブラリは次のようにして strip されているべきです。

     strip --strip-unneeded your-lib

(このオプション `--strip-unneeded' は strip にリロケーション処理に必要のないシンボルのみを削除するように指示します) ダイナミックリンクの際に使用するシンボルは別の ELF オブジェクトにあるので、共有ライブラリは strip されても完全に機能 [86] します。

ある種の場合、たとえばデバッグ機能を持った別パッケージをビルドする場合など、 strip しない共有ライブラリを作成したほうがいい場合もあることに気をつけてください。

共有のオブジェクトファイル (多くの場合は、 .so ファイルです) で、汎用のライブラリではない (すなわち、一連のものとは独立の実行ファイル (バイナリや他のパッケージからリンクされることを想定していない) ものは、/usr/lib ディレクトリのサブディレクトリにインストールすべきです。 このようなファイルは通常の共有ライブラリに適用される規則に沿わなくともかまいませんが、 実行可能ビットを立ててインストールしてはいけないこと、及び strip すべきこと、の二つの規則は守る必要があります [87]。

共有ライブラリを作成・インストールする際に libtool を使うパッケージは、追加のメタデータを含むファイル (.la という拡張子を持つファイル) をライブラリ以外にインストールします。 他のパッケージからの利用を想定した公開ライブラリでは、これらのファイルを Debian パッケージには通常は収録すべきではありません。 これは、このファイルに含まれる情報は、Debian では共有ライブラリとリンクする際に必要ではなく、さらに他のプログラムやライブラリへの不要な依存関係を追加してしまうためです[88]。 ライブラリに .la ファイルが必要な場合 (例えば、 メタ情報が必要となるやり方で libltdl よりロードされる場合など) .la ファイルの dependency_libs 設定には、通常は空文字列をセットすべきです。 共有ライブラリの開発向けパッケージで、歴史的な経緯から .la が含まれている場合、開発向けパッケージには、それに依存している全てのライブラリに収録された .la ファイル内の dependency_libs が削除されるか空になるまで (つまり、libtool を使った他のパッケージのリンクが失敗しないようになるまで)、 それを維持 (dependency_libs を空にして) しなければいけません。

.la を含めなければならない場合で、ライブラリが libtoollibltdl ライブラリからロードされるのでなければ、 .la ファイルは開発用パッケージ (-dev) に含めるべきです。 libltdl での利用を想定している場合には、.la ファイルはランタイムパッケージに含めなければいけません。

以上の .la ファイルの扱いに関する規定は、ローダブルモジュールや、 標準状態ではダイナミックリンカがサーチしないディレクトリにインストールされるライブラリに対しては適用されません。 ローダブルモジュールをインストールするパッケージは、多くの場合モジュールに加えて .la ファイルをインストールし、libltdl によってロードできるようにする必要があるでしょう。 dependency_libs は、ダイナミックリンカがサーチしないディレクトリにインストールされ、 他のパッケージからの利用を意図していないライブラリやモジュールの場合は、変更する必要はありません。

自分のパッケージを作成する際には、リリースされている版の共有ライブラリのみを使うように気をつけなければいけません。 ここで間違えるとほかのユーザはあなたのプログラムを正しく実行することができません。 リリースされていないコンパイラに依存するパッケージを作成することも通常好ましくありません。


10.3 共有ライブラリ

この節は 共有ライブラリ, Chapter 8 に移されました。


10.4 スクリプト

パッケージ中に含まれ dpkg が使用するメンテナスクリプトも含めて、すべてのコマンドスクリプトはスクリプトを解釈するインタープリタを #! 行を追加して指定しなければいけません。

それが perl スクリプトの場合は、その行は #!/usr/bin/perl でなければいけません。

シェルスクリプトをシステムの PATH 内のディレクトリにインストールする場合、スクリプト名には .sh.pl などの、スクリプトを実装するのに現在使っている言語を示す拡張子を含めるべきではありません。

シェルスクリプト (shbash を使う) で、init.d 以外のものは、特殊な場合をのぞいて最初に set -e を書いてエラーを検出するようにすべきです。 init.d スクリプトはここでは特殊な場合で、失敗することが許されるコマンドを実行する必要がある頻度が異なるため、代わりにコマンドの終了ステータスをチェックするほうが容易でしょう。 init.d スクリプトについての詳細は スクリプトの書き方, Section 9.3.2 を参照ください。

全てのスクリプトは、set -e を使うか、すべての コマンドの終了ステータスをチェックすべきです。

スクリプトは、SUSv3 Shell Command Language 規定[89]の仕様に沿っており、かつ SUSv3 で必須とはされていない以下の機能 [90] をもつような /bin/sh の実装であることを仮定してかまいません。

もし、シェルスクリプトが上記記載以外の SUSv3 規定外の機能をシェルインタープリタで必要とする場合、適切なシェルをスクリプトの最初の行に (例えば #!/bin/bash のように) 指定しなければならず、 そのシェルを提供しているパッケージに対する依存関係をパッケージで指定しなければいけません (そのシェルパッケージが "Essential" 扱いになっている、例えば bash のような場合は依存関係の指定は不要です)。

スクリプトをできる限り SUSv3 規定の機能および上記の追加機能だけを用いて書くようにし、 /bin/sh をインタープリタとして使えるようにしたいと思う場合、あなたのスクリプトを devscripts パッケージの checkbashisms を使ってチェックするか、posh などの代替シェルでスクリプトを動かしてテストを行えば、上記の制限に対する違反の発見に有益でしょう。 但し、疑問があるなら明示的に /bin/bash を使ってください。

Perl スクリプトでは、システムコールを使ったときにはエラーをチェックしてください。 システムコールには openprintcloserenamesystem などが含まれます。

cshtcsh をスクリプト言語に使うのは避けるべきです。 この理由は comp.unix.* の FAQ の一つ Csh Programming Considered Harmful (http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/) を参考にしてください。 上流のパッケージに csh スクリプトが含まれているときには、 そのスクリプトが #!/bin/csh で始まり、そのパッケージを c-shell 仮想パッケージに依存するよう設定したことをよく確認してください。

誰からでも書けるディレクトリに (例えば /tmp に) ファイルを作成するスクリプトは、作成しようとするファイルと同じ名前のファイルが存在したら、他に何もせずに失敗するような機構を組み込んでください。

Debian の base システムに含まれる tempfilemktemp ユーティリティはこの目的でスクリプト中で使うためのものです。


10.5 シンボリックリンク

通常、トップレベルディレクトリ (ルートディレクトリ / のサブディレクトリがトップレベルディレクトリです) 内のシンボリックリンクは相対参照とすべきです。 また、トップレベルディレクトリ間のシンボリックリンクは絶対参照とすべきです。 例えば、/usr/lib/foo から /usr/share/bar へのシンボリックリンクは相対参照とすべき (../share/bar) ですが、 /var/run から /run へのシンボリックリンクは絶対参照とすべきです [91]。

それに加えて、シンボリックリンクは可能な限り短くすべきです。 例えば foo/../bar のような参照は好ましくありません。

ln を使って相対リンクを作成するときに、ln を実行する作業用ディレクトリからの相対位置にリンク先が存在している必要はありません。 また、リンクを作成しようしているディレクトリに作成の際にディレクトリを移動する必要もありません。 やるべき事は単にリンク先 (リンクが存在するディレクトリからの相対参照になるようなパス名です) が ln の最初の引数に現れるよう文字列を与えるだけです。

例えば、Makefiledebian/rules で次のような処理を行ってください。

     ln -fs gcc $(prefix)/bin/cc
     ln -fs gcc debian/tmp/usr/bin/cc
     ln -fs ../sbin/sendmail $(prefix)/bin/runq
     ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq

圧縮されたファイルを参照するシンボリックリンク (unzip または zless などで伸長することを意図したもの) は、対象ファイルと同じ拡張子を持つようにすべきです。 例えば、foo.gz をシンボリックリンクで参照する場合、リンクのファイル名も同様に ".gz" で終わる、bar.gz のような名前にしてください。


10.6 デバイスファイル

パッケージファイルツリーにデバイスファイルや名前付きパイプを含めることは許されていません。

パッケージが base システムに含まれていない特殊なデバイスファイルを必要とする場合には、 postinst スクリプト中でユーザに許可を問い合わせた後 MAKEDEV を呼び出してください[92] 。

パッケージから postrm や、その他のスクリプト中でデバイスファイルを削除してはいけません。 そのような処置は管理者に任せてください。

Debian ではシリアルデバイスファイル名に /dev/ttyS* を使います。昔流の /dev/cu* を使っているプログラムは /dev/ttyS* に変更すべきです。

パッケージで必要な名前付きパイプは、postinst スクリプトで作成しなければいけません [93]。また、必要に応じて prerm または postrm スクリプトで削除しなければいけません。


10.7 設定ファイル


10.7.1 定義

設定ファイル

これは、プログラムの実行に影響を与えるファイル、 またはサイトやホスト固有の情報を提供するファイル、 またはプログラムの挙動を制御するためのファイルです。 通常、設定ファイルはシステム管理者の手で、 ローカルの方針やサイト個別要件にあわせた挙動をさせるために、 必要に応じて変更されることを想定しています。

conffile

パッケージの conffiles ファイル中に列挙されたファイルで、dpkg から特別の扱いを受けます (設定の詳細, Section 6.7 参照)。

この二つの違いは重要で、置きかえ可能な概念ではありません。 ほとんどすべての conffiles は設定ファイルですが、 多くの設定ファイルは conffiles ではありません。

別途記載されているとおり、/etc/init.d スクリプト、 /etc/default ファイル、 /etc/cron.{hourly,daily,weekly,monthly} 中のスクリプトや /etc/cron.d 中の cron の設定ファイルなどは「設定ファイル」として扱わなければいけません。 一般的に、設定情報を内部に持つスクリプトはは事実上の設定ファイルですし、そのように扱われます。


10.7.2 設定ファイルの置き場所

パッケージによって作られ使われる設定ファイルは /etc 以下に配置しなければいけません。 関連した設定ファイルが複数ある場合には、そのパッケージの名前がついたサブディレクトリを /etc 以下に作成することを検討してください。

あなたのパッケージが /etc 以外の場所に設定ファイルを作成し、かつそのパッケージが /etc を使うように修正するのが望ましくない場合でも、 設定ファイル自体は /etc に置き、 パッケージの期待する場所からシンボリックリンクで参照するようにするべきです。


10.7.3 設定ファイルの扱い

設定ファイルの扱いは下記の挙動に従ったものとしなければいけません。

ローカルでの修正の無い、廃止になった設定ファイルはアップグレードの際に削除しても構いません[94]。

この挙動を行わせるやさしい方法は設定ファイルを conffile にしてしまうことです。 これはほとんどのインストールの場合にそのままで使え、 一部のシステム管理者が変更するかもしれない、そういう設定ファイルを添付できる場合だけに適した方法です。 更に、この方法を使うためには標準設定のファイルがパッケージの配布物に含まれていること、またインストール中 (やその他の際に) にメンテナスクリプトから書き換えを行わない、という二条件を満たしている必要があります。

パッケージの conffile にハードリンクを張ることは、ローカルで加えた変更を正しく残せなくなるため、許されていません [95]。

もう一つのやり方は、上記の挙動をメンテナスクリプトから実現する方法です。 この場合には設定ファイルは conffile として列挙してはならず、またパッケージ配布物に含まれていてもいけません。 パッケージにまずまずの設定を行うために、なんらかの設定ファイルが存在していることが必要な場合でも、 設定ファイルを作成し、更新し、維持し、完全削除の際に削除するようなメンテナスクリプトを提供することはパッケージメンテナの責任です (詳細は パッケージ管理スクリプトとインストールの手順, Chapter 6 を参照ください)。 このスクリプトは結果の再現性を持たなければいけません (すなわち、dpkg がインストール中のエラーや、パッケージの削除のためスクリプトを再実行した場合に正しく動作しなければならないということです)。 また、このスクリプトは dpkg がメンテナスクリプトを呼び出す様々なやり方に対応できねばならず、 ユーザの設定ファイルを前もって問い合わせることなしに上書きしたり壊したりしてはいけません。 またこのスクリプトは、特にアップグレードの時には、不必要な質問を行ったりせず、善良な市民として振る舞わなければいけません。

スクリプトはパッケージに設定しうるすべてのオプションを設定しなければならないわけではなく、 与えられたシステムでパッケージが動作するために必要な設定だけを行えばかまいません。 理想的なことを言えば、システム管理者が postinst で (半) 自動的に行われた設定以外のことを行う必要がないのが、あるべき姿です。

通常取られる手法は package-configure という名のスクリプトを作成し、パッケージの postinst から設定ファイルが存在していないときのみ、そのスクリプトを呼ぶようにするやり方です。 時にはメンテナスクリプトが使う例や雛形ファイルを用意すると便利なこともあります。 そのようなファイルがある場合、アーキテクチャへのの依存関係の有無に沿って、 /usr/share/package または /usr/lib/package に置きます。 それが例なら /usr/share/doc/package/examples からそこへシンボリックリンクを作成してください。また、通常の dpkg で処理するファイルにして (すなわち、 設定ファイルでは無いようにする) ください。

これまで説明してきた設定ファイルの扱いの手法は混在させてはいけません。 それは、はちゃめちゃへの一本道です。 dpkg がパッケージをアップグレードする際に毎回ファイルを上書きするかどうか問い合わせてくるようになり、頭を掻きむしることになります。


10.7.4 設定ファイルの共用

もし二つ以上のパッケージが同じ設定ファイルを使用し、 それらのパッケージを同時にインストールしても問題がない場合には、 これらのパッケージのうちの一つを設定ファイルの 所有者 (owner) と定義してください。 これはその設定ファイルを管理し、扱うパッケージです。 ほかのその設定ファイルを使用するパッケージは、 動作時にその設定ファイルが必要ならば、所有者となったパッケージに依存 (depend) する必要があります。 もしほかのパッケージが、その設定ファイルがあれば使うけれども、そのファイルが無くても動作はするということならば、依存関係の宣言は不要です。

もし二つ以上のパッケージが同じ設定ファイルを使用し、 かつ これらのパッケージが設定ファイルを変更する場合がある、という状況下では、以降の各項を満たすようにしてください。

  • 関連したパッケージの一つ (『所有者』パッケージ) が前節で説明した方法で、メンテナスクリプトから設定ファイルを管理するようにします。

  • 『所有者』パッケージは他のパッケージが設定ファイルを変更する際に用いるプログラムを提供しなければいけません。

  • 関連するパッケージは設定ファイルを変更する際には上で記した 『所有者』パッケージの提供するプログラムを使わなければいけません。 また、関連するパッケージは変更のためのプログラムが存在することを保証するために『所有者』 パッケージに依存することを宣言するか、変更のためのプログラムがなかったときにはエラー等を出さず変更をあきらめるようにするかの、 どちらかとしておかなければいけません (後者のシナリオでは、設定ファイルが存在していない場合に加えこの考慮も必要になります)。

  • 場合によっては、他のパッケージの基本的な土台を作成し、共有の設定ファイルを管理する新パッケージを作成した方がいいこともあります (例として sgml-base パッケージを参考にしてください)。

    設定ファイルが上記記載のように共有できない場合は、これらのパッケージは互いに競合していると指定されなければいけません。 同じファイルを指定しているパッケージ間は 競合 (conflict) していると指定しなければいけません。 これはファイルを共有してはいけないという一般則から来ています。 この場合は代替 (alternative) や待避 (diversion) の指定は適しません。 特に、dpkg は待避時の conffile をうまく扱えません。

    2つのパッケージが同じ conffile を宣言している場合、それらパッケージが互いに conflict を指定している場合でも、設定が残っている状況になる場合があります。 もしユーザが一方のパッケージを削除 (完全削除ではなく) し、他方のパッケージをインストールした場合、新しいパッケージは古いパッケージの conffile を引き継ぐことになります。 もしファイルがユーザの手で変更されていた場合、これはアップグレードの際には、 ローカルで変更されていた conffile と同じ扱いを受けます。

    The maintainer scripts must not alter a conffile of any package, including the one the scripts belong to. メンテナスクリプトは、それ自身が収録されたパッケージを含む いかなるパッケージの conffile を変更してもいけません。


    10.7.5 ユーザ設定ファイル (ドットファイル)

    /etc/skel にあるファイルは adduser に よって自動的に新ユーザのアカウント下にコピーされます。この /etc/skel 以下は他のどのプログラムからも参照しては いけません。

    この関係で、プログラムが動作するのに $HOME ディレクトリにドットファイルをあらかじめ用意しておく必要があるならば、 ドットファイルはあらかじめ /etc/skel にインストールしておき、設定ファイルとして扱うべきです。

    とは言っても、正しく動作するために自分で自動的に作成するもの以外のドットファイルが必要なプログラムというものは、望ましいものではありません。

    加えて、プログラムは Debian の標準インストール状態で、上流のデフォルトにできるだけ近い動作をするように設定されているべきです。

    したがって、Debian パッケージのプログラムを真っ当に動くようにする設定が必要なら、 /etc 内にサイト共通で利用する設定ファイルを用意してください。 プログラムがサイト共通の標準設定ファイルをサポートしておらず、 パッケージメンテナがその機能を追加する余裕がないときは、 /etc/skel にユーザ個別のファイルをおいてもかまいません。

    /etc/skel はできる限り空になるようにしましょう。 パッケージをインストールしたときに、ドットファイルを現存のユーザにコピーする簡単な (そして、適切な) 仕組みがないことからも、そうすべきなのは明らかだと思います。


    10.8 ログファイル

    ログファイルは通常 /var/log/package.log という名にします。たくさんの log ファイルを持つ場合や、 読み書き権限の設定のために独立のディレクトリを必要とする場合には (/var/logroot ユーザからのみ書き込めます)、 通常は /var/log/package という名のディレクトリを作成してそこにログを置くべきです。

    ログファイルは時々循環させるようにして、どこまでも大きくなることがないようにしなければいけません。 これを実現する最良の方法は、/etc/logrotate.d ディレクトリにログ循環設定ファイル (通常、 /etc/logrotate.d/package という名前です) を置き、logrotate の提供する機能を使うやり方 [96] です。 次に logrotate の設定ファイルのいい例を挙げましょう (詳しくは logrotate(8) を見てください)。

         /var/log/foo/*.log {
             rotate 12
             weekly
             compress
             missingok
             postrotate
                 start-stop-daemon -K -p /var/run/foo.pid -s HUP -x /usr/sbin/foo -q
             endscript
         }
    

    上記の例は /var/log/foo 以下の全ファイルを巡回させ、12 世代分保存し、循環終了時にデーモンに設定ファイルを再オープンさせるものです。 もしログがなかった場合にはログ循環をスキップする (missingok 経由で) ようになっており、パッケージが削除されているが完全削除状態でない場合にエラーにならないようにしています。

    パッケージが完全削除 (purge) された時には、ログファイルがすべて消去されるよう (パッケージが削除されたときには消しません) にすべきです。 これは postrm スクリプトが引数 purge で呼ばれた際に行ってください (削除と設定の完全削除の詳細, Section 6.8 参照)。


    10.9 ファイル属性と所有者

    この節のここ以降で記載されているのは一般的なガイドラインですので、 必要に応じて細部でここから離れてもかまいません。 しかしながらやっていることがセキュリティ上問題がないこと、 またシステムのほかの部分との整合性を可能な限り維持していることを必ず確認してください。 おそらくまず debian-devel で相談するのがいいでしょう。

    ファイルは root:root の所有権で、所有者書き込み可能で誰でも読める (および適宜実行可能である) ようにしてください。 すなわち、ファイルモードは 644 か 755 になります。

    ディレクトリのパーミッションは 755、あるいは、グループが書き込み可であれば 2775 にすべきです。ディレクトリの所有者は パーミッションに合わせてください。 つまりディレクトリのパーミッションが 2775 であれば、そこに書き込む必要のあるグループのユーザを所有者に設定してください [97]。

    制御情報ファイルは、root:root の所有権で、パーミッション 644 (ほとんどのファイルでは) か、755 (maintainer scripts などの実行可能なファイル) にすべきです。

    setuid や setgid された実行ファイルのパーミッションはそれぞれ 4755、2755 で、適切な所有者とグループに設定されねばなりません。 それらを読み込み不可 (4711 や 2711、4111 など) にしてはいけません。 誰でも自由に利用可能な Debian パッケージのバイナリを探してくることができるので、読み込み不可にすることはセキュリティ対策にはならず、単に不便にするだけです。 同じ理由で set-id していない実行ファイルに対して読み込み・実行許可を制限すべきではありません。

    setuid を使う一部のプログラムではファイルのパーミッションを使って、 実行をある特定のユーザのみに制限する必要があります。 この場合 set-id したいユーザの uid を所有者として、実行を許可されたグループに実行許可を与えます。 この時のパーミッションは 4754 です。 繰り返しますが、実行を許さないユーザに対して読み込み不可にすることは、前述の理由で意味がありません。

    システム管理者がローカルなセキュリティの方針に合わせるため、 各バイナリのパーミッションを変えてパッケージを再設定する枠組にしてもかまいません。 その場合は、以下で記載の通り dpkg-statoverride [98] を使うことができます。 もう一つの方法として、例えばプログラムを利用することができるグループを作り、 setuid した実行ファイルはそのグループだけが実行できるような設定とすることもできます。

    パッケージのために新しいユーザまたはグループを作成する必要がある場合、二つの方法があります。 第一の方法は、このユーザまたはグループを所有者としてバイナリパッケージの所定のファイルを作成します。 または、バイナリに単なる名前ではなくユーザあるいはグループ ID をコンパイル時に埋め込むようにもできます (この方法は静的に割り当てられた ID が必要となるため、可能な限り避けるべきです)。

    静的に割り当てられた id が必要な場合、base-passwd システムの管理者にユーザあるいはグループ ID の割り当てを求めます。 割り当てられるまでパッケージをリリースすることはできません。 このようなユーザやグループが割り当てられたらならば、パッケージは当該 ID を /etc/passwd ないしは /etc/group に含むような base-passwd パッケージの特定以降のバージョンに依存するようにするか、 パッケージ中の preinst または postinst スクリプト等で、割り当てられた ID を (adduser などを使って) 自分で作成するようにしてください。 postinst で行うほうが、可能ならばより良いやり方です。 preinst を使う場合、adduser パッケージに対する先行依存関係の宣言が必要になります。

    第二の方法は、プログラムが実行時にグループ名から uid、gid を決定するようにするもので、ID は動的に [99] 割り当てられます。この場合、debian-devel で討議を行ない、また base-passwd のメンテナにその名前が一意であること、静的に ID を割り当てたほうが望ましいということがないか、の二点を問い合わせて、その後適切なユーザ名あるいはグループ名を選ぶべきです。 これらの確認がすんだ後パッケージの preinstpostinst スクリプトで (繰り返しますが後者が好ましいです) 必要に応じて adduser を使ってユーザあるいはグループを作成するようにしてください。

    名前に関連した ID の値を変えることはとても難しく、全ての関連したファイルをファイルシステムから検索する必要があることに注意してください。 後になってからの変更は問題を起こしますので、ID は静的か動的か良く考えて決めてください。


    10.9.1 dpkg-statoverride の使い方

    この節はポリシーの一部ではなく、dpkg-statoverride の使い方について解説することを意図しています。

    システム管理者が配布状態の Debian パッケージと異なる所有者またはパーミッションでファイル (またはディレクトリなど) をインストールしたい場合、 ファイルがインストールされる際に毎回異なった設定を使うよう dpkg に指示を出すため dpkg-statoverride を使うことができます。 これによって、パッケージメンテナは標準のパーミッションでファイルを配布しておき、システム管理者が望む変更を加えられるようにすることができます。 例えばあるデーモンは通常 setuid root が必要になりますが、 ある特定の状況では setuid なしに使えるという場合、 .deb パッケージでは setuid 付きでインストールすべきです。 この場合、ローカルのシステム管理者が望みに応じてこれを変更することができます。 また、もしインストールの際に標準的な設定が二つある場合であれば、メンテナは debconf を使って好ましい選択を聞き、メンテナスクリプト中から dpkg-statoverride を呼んでシステム管理者の選択を適用することができます。 アップグレードの際に、既存の設定を上書きしないような配慮を行わなければいけません。

    上記の通り、dpkg-statoverride は主にシステム管理者のためのツールで、メンテナスクリプトで必要になることは普通ありません。 但し、このような dpkg-statoverride の呼び出しがメンテナスクリプトで必要になる場合があります。 その一例が、動的に割り当てられたユーザやグループ ID を使う場合です。この場合、パッケージの postinst で以下の定石が参考になるでしょう。 ここで、sysuser が動的に割り当てられた ID 名です。

         for i in /usr/bin/foo /usr/sbin/bar
         do
           # only do something when no setting exists
           if ! dpkg-statoverride --list $i >/dev/null 2>&1
           then
             #include: debconf processing, question about foo and bar
             if [ "$RET" = "true" ] ; then
               dpkg-statoverride --update --add sysuser root 4755 $i
             fi
           fi
         done
    

    以下はパッケージ完全削除 (purge) の際、override を削除するコードです。

         for i in /usr/bin/foo /usr/sbin/bar
         do
           if dpkg-statoverride --list $i >/dev/null 2>&1
           then
             dpkg-statoverride --remove $i
           fi
         done
    

    10.10 ファイル名

    システムの PATH (具体的には /bin, /sbin, /usr/bin, /usr/sbin および /usr/games) にバイナリパッケージからインストールするファイル名は ASCII エンコーディングを用いなければいけません。

    システム PATH 外にバイナリパッケージからインストールするファイル名は UTF-8 でエンコーディングしなければいけません。 また、可能な限り ASCII 範囲内に制限するべきです。


    [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]


    Debian ポリシーマニュアル

    バージョン 3.9.5.0, 2014-07-03

    The Debian Policy Mailing List