|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
Unix 上のハードディスクには、いろいろな名前がついたディレクトリやファイルが 階層的に並んどるのを知ってはるや思うで。通常はそれ以上深く探求する必要は ありまへんのやが、ディスクがクラッシュして内部のファイルをどないかして復活させる 必要が生じた場合には、その水面下で何が起こっとるんかを知っとることは どエライ有益になるんですわ。残念ながら、ディスクの仕組みについて普段目にしてん ファイルのレベルから段々ねちっこく説明するような分かりやすい方法があらへんさかい、 ここでは、ハードウェアレベルの説明から始めて、じょじょに日常的な操作の 方に話をもっていくようにしたい思うで。
ディスクの表面ちうは、データが保持される場所なわけやけど、そやけどアンタ、ここは、 ダーツの的のように幾つかの構成部分に分割されとりまんねん。同心円状の トラックが何本も走ってて、それらのおのおのが、パイを切り分ける ときのようにセクタに分けられとりまんねん。ディスクの外周に近いトラックの ほうが中央のスピンドルに近いトラックよりも領域が広いさかい、外周の トラックは、内周のトラックよりも数ようけのセクタに分割されとりまんねん。 個々のセクタ (もしくは、ディスクブロック (disk block) とも言おります) は、同一サイズとなって おりますわ。こら、現在の Unix 系 OS では、一般的には、1 バイナリ k (1024 8-bit ワード) となっとりまんねん。それぞれのディスクブロック には、固有のアドレス、言いかえると ディスクブロック番号(disk block number) が付けられとりまんねん。
Unix は、ディスクをディスクパーティション (disk partition) へと分割しまっせ。個々のパーティションは、連続したディスクブロック から成る一定のディスク領域なんやし、そないなパーティションは、 他のパーティションとはまるっきし独立した領域として、ファイルシステムか スワップスペースとして扱われはります。パーティションを分割する もともとの理由は、まだディスクのアクセス速度が今よりずっと遅く、 アヤマチも多かった時代において、ディスククラッシュに対処するため やった。各パーティションの間に境界を設けることによって、 ディスクの一部が、その中にランダムに発生する不良個所によって、 アクセスできなくなりよったり、カンペキに破壊されたりする可能性を軽減しとった のや。現在、パーティション分割は、より重要性を増してるんや。すなわち、 (悪意を持った侵入者が重要なシステムファイルを書き換えてまう ことを防止するために) 特定のパーティションを読み出し専用にしたり、 この文書では触れへんような各種の手段によって、ネットワーク越しに 共有可能に設定したりできるさかいや。最も若い番号が付いたパーティション は、たいてい、ブートパーティション (boot partition) として 特別な扱いを受けまんねん。ブートパーティションとは、起動すべきカーネルを 置くことができるパーティションのことや。
個々のパーティションは、(仮想メモリを実装する ために利用される) スワップスペース (swap space) か、ファイルを保持するために利用される ファイルシステム ( file system) かのどちらかや。スワップスペースのパーティション は、連続した一連のディスクブロックとして扱われはります。それとは異なり、 ファイルシステムには、ファイル名をディスクブロックに対応付ける仕組みが 必要や。ファイルは時間の経過とともにサイズが増減したり中身が変わったり するんで、ファイルのデータブロックちうんは、連続して並んどる わけやのうて、該当するパーティション全体に散らばっとることが ようおます(オペレーティングシステムは、使用中やないディスクブロックを それがパーティション中のどこにあるかには関係なく使うように出来とる からや)。こないな風にディスクブロックが各所に散らばった場合の 症状は フラグメンテーション (fragmentation) と呼ばれとりまんねん。
各ファイルシステム内では、ファイル名とディスクブロックとの対応関係は、 i-node と呼ばれる構造体 (structure) を媒介にして処理されとりまんねん。こないな事柄に関する 情報は、ファイルシステムのアタマ部分 (小さな番号のディスクブロック群) に 保存されとります(実際に最小の番号を持つディスクブロック群は、ここでは説明は しまへんが、情報の整理とラベリングの目的で利用されはる)。ひとつの i-node が ひとつのファイルの情報を記述するようになっとりまんねん。(ディレクトリを 含む) ファイルのデータブロックは、i-node よりも上の領域 (大きな番号を もつディスクブロック上)に置かれとりまんねん。
個々の i-node には、じぇったいそれが記述するファイルに属するディスク ブロックの番号のリストが含まれとりまんねん。(こら、実際には小さなファイル の場合にしか当てはならへんのやけど、例外に関する詳細はここでは 重要性を持ってへんねん。) 用心してほしいんは、i-node には、ファイル名に ついての情報は含まれんということや。
ファイル名は、ディレクトリ構造体 (directory structure) のなかにおます。すなわち、 ディレクトリ構造体が、ファイル名を i-node に対応付けとるわけや。 Unix では、ひとつのファイルが正式なファイル名を複数持つことが 可能になっとる(こら、ハードリンク (hard links) とも言おります) んは、このためや。 それらは複数のディレクトリエントリなんやし、ぜええんぶひとつのこらずが同一の i-node をポイントしてるんや。
最も単純な構成では、Unix ファイルシステムの全体は、たったひとつの ディスクパーティションに格納するっちうことができまんねん。こないな構成を 小さな個人用の Unix システム上で見はることがあるとしたかて、 この構成は一般的なもんであるとはいえしまへん。むしろ、複数の ディスクパーティションにまたがって構成されるのが普通や。 それやから、例あげたろか、たとえばやなあ、小さなパーティション上にカーネルを置いて、 ちびっと大きめのパーティションに OS のユーティリティを置き、 さらにどエライ大きなパーティションをユーザのホームディレクトリに するといった構成が考えられはります。
システムの起動直後にアクセスするパーティションは、 ルートパーティション(root partition) だけや。起動の際は、(ほぼ、じぇったい)ここから起動されるゆう場所や。 ここには、ファイルシステムのルートディレクトリがあり、他のずぅぇえええぇぇええんぶの 起点となる最上位の階層(top node)や。
複数のパーティションを持つファイルシステム全体へのアクセスを可能にするには、 ファイルシステム内にあるそれ以外のパーティションを、このルートパーティション に付け加えていかなならしまへん。起動プロセスのやいたい中ほどで、Unix はこないなルート以外のパーティションをアクセス可能にしまっせ。その際、Unix は、そないなパーティションのおのおのを、ルートパーティションにある ディレクトリ上に マウント(mount) しまっせ。
例あげたろか、たとえばやなあ、/usr ちうディレクトリが Unix 上にある 場合、ワイが思うにはここはマウントポイントなんやし、インストールされたプログラム のうち、システムの起動に必要のあらへんもんを置いとるパーティションが マウントされる場所になっとるはずや。
ここまでの説明で、上部構造から下部構造を眺める準備ができましたのや。読者が ファイルを開くとき (例あげたろか、たとえばやなあ、/home/esr/WWW/ldp/fundamentals.sgml ちう名前やとします)、実際の動作は次のようになっとりまんねん。
カーネルは、まず (ルートパーティションにあるんや) Unix ファイルシステムの ルートディレクトリから検索を開始しまっせ。カーネルは、ルートディレクトリで 'home' と呼ばれるディレクトリを探しまっせ。たいてい、'home' は、ルート パーティションとは別の、巨大なユーザパーティションのマウントポイント であるんで、カーネルはそのパーティションに移動しまっせ。そのユーザパーティション の最上層のディレクトリ構造体の中で、カーネルは 'esr' と呼ばれるエントリを 探し、その i-node 番号を抽出しまっせ。カーネルがその i-node のある場所に 行くと、それに関連付けられはったファイルのデータブロックがディレクトリ構造体に なっとることに気付き、それやから次に 'WWW' を探しまっせ。ほんで、その i-node を抽出したら、今度は、その i-node に該当するサブ ディレクトリに行ちう、'ldp' を探しまっせ。こら、さらに別のディレクトリ i-node へとカーネルを導きまんねん。そのディレクトリを開くと、ほんで 'fundamentals.sgml' ファイルの i-node 番号を見つけまんねん。この i-node が ディレクトリやのうて、そのファイルに関連付けられはったディスクブロックの リストを保持してるんや。
プログラムが、事故や他人の悪意ある行為によって、本来アクセスでけへん はずのデータ領域に侵入するんを防ぐために、Unix には、 パーミッション (permission) ちう機能がおます。この機能はもともと、 昔まだ Unix が主に高価なミニコンピュータとして大勢で共有して利用されて いた頃、同一マシン上の複数のユーザが相互に干渉せんようにするっちうことで、 時分割方式をサポートするために設計されたんですわ。
ファイルのパーミッションを理解するには、ログインしたときに何が起こるか?のセクションにあった ユーザとグループの説明を思い出す必要がおます。個々のファイルには、 それを所有するユーザとグループとがおます。それらは、当初 そのファイルの作成者のユーザ名やグループ名が付けられはるが、 chown (1) や chgrp (1) と いうプログラムを使うてそれらを変更するっちうこともできまんねん。
ファイルに関係付けられはる基本的なパーミッションには、`read' (そこから データを読み出せるゆう権限)、`write' (それを変更するっちうことができる 権限)、および `execute' (それをプログラムとして実行するっちうことが できる権限)ちうのがおます。ほんで、個々のファイルは、こないな パーミッションのセットを三つ持っとりまんねん。ひとつは、ファイル 所有者用に、もうひとつは所有グループに属する全ユーザ用に、 ほんで三つ目はそれ以外のずぅぇえええぇぇええんぶの人用のもんや。ユーザがログイン時に 取得する「権限 (privilege)」ちうんは、ファイルのパーミッションビット が許可してん範囲での読み・書き・実行権限となるんですわ。すなわち、 ユーザのユーザ ID が、ファイルに付された ID と一致する場合は、 その範囲での権限を取得し、所属グループが一致する場合は、ほんでの権限、および どなたはんもがアクセスできるファイルの場合は、ほんで規定された権限を取得 するっちうことになるんですわ。
これらのパーミッションが相互にどないな働きをしてんか、Unix で どないな風に表示されるんかを知るために、仮に以下のような Unix システムがある として、そのファイルの一覧を見てみまひょ。例あげたろか、たとえばやなあ、次のように表示 されたとしまっせ。
snark:~$ ls -l notes -rw-r--r-- 1 esr users 2993 Jun 17 11:00 notes |
上記は通常のデータファイルや。この表示から分かることは、このファイルは、 ユーザ `esr' が所有するもんなんやし、所有グループ `users' に属するもんと して作成されたゆうことや。ここで例として挙げたマシンでは、通常の ユーザはずぅぇえええぇぇええんぶこのグループに属するようわ、デフォルトで設定されとるの でっしゃろ。タイムシェアリングマシン上でよう見かけるそれ以外のグループ名 には、`stuff' や `admin' 、 `wheel'やらなんやらがおます(理由はお解りに なる思うんやが、個人ユーザ用のワークステーションや PC 上では、 グループはそれほど重要やおまへん)。読者の Unix 上では、 デフォルトでちゃうグループ名が使用されとるかもしれしまへん。 ワイが思うには、読者のユーザ ID をもとにして、名前が付けられとることでっしゃろ。
文字列 "-rw-r--r-" ちうんは、ファイルのパーミッションビットを表して おりますわ。アタマのダッシュ(-)は、ディレクトリビットを表示する位置や。 もしこのファイルがディレクトリやったやったら、そこには "d" と表示され まんねん。それ以降の位置については、最初の三つがユーザパーミッション、 次の三つがグループパーミッション、その後の三つがそれ以外の人のための パーミッション(こら、"world" permission とも呼ばれとります)や。 このファイルの場合、所有者 "esr" は、ファイルの読み出し・書き込みが でき、"users"グループに属する所有者以外の人はファイルの読み出し、 および全ユーザがファイルの読み出しを出来よるようになっとりまんねん。 こら、通常のデータファイルとしてどエライ典型的なパーミッションの 設定や。
次に、上記とはごっつう異なりよったパーミッションを設定されたファイルを見てみまひょ。 このファイルは、GCC, すなわち、GNU C コンパイラや。
snark:~$ ls -l /usr/bin/gcc -rwxr-xr-x 3 root bin 64796 Mar 21 16:41 /usr/bin/gcc |
上記ファイルは、"root" ちうユーザに属し、"bin" ちうグループ に所属してるんや。また、書き込み(変更)は "root" しかでけしまへんが、 読み出しと実行はどなたはんもができるようになっとりまんねん。こないな設定は、 プレインストールされとるシステムコマンドにようある所有形態および パーミッション設定や。"bin" とういグループは、Unix 上で システムコマンドをグループ化するんに使われたりします(この名称は 歴史的な名残なんやし、"binary" の省略形や)。読者の Unix では、 "root" ちうグループ名が使われとるかもしれしまへん(こら、 "root" ユーザちうのとはちーとばかしちゃいます)。
"root" ユーザちうんは、ユーザ ID 番号 0 のユーザの慣用的な名称や。 こら、ずぅぇえええぇぇええんぶの権限設定を超越した、特別かつ特権的なアカウントや。 root でのアクセスは、便器...おっとちゃうわ、便利ではおますが、危険でもおます。root でログイン してん間にタイプミスをすると、通常のユーザアカウントから同じコマンドを 実行した場合にはいらうことすらでけへんような重要なシステムファイルを カンペキに破壊してまうことがあるからや。
root アカウントはどエライパワフルやから、root へのアクセスは慎重にガード せなならしまへん。root のパスワードは、システムのセキュリティ情報と しては最重要項目なんやし、他人のシステムを狙うクラッカーや侵入者が何よりも 取得したろおもて目論むのが、この root パスワードや。
パスワードは、決して書き留めたりしてはいけまへん。また、ボーイフレンド やガールフレンド、配偶者の名前のような、簡単に推測が つくようなパスワードを選んやりもせんでおくんなはれ。こら、 おったまげるほど広く蔓延してん悪癖なんやし、クラッカーにいつまでも 手を貸すようなもんや。一般に、辞書に載っとるような単語を 選んではいけまへん。dictionary crackers と呼ばれるプログラムがあり、こら一般的な単語の一覧を使うて、 推測でパスワードを探し当てんねんもんや。悪うへんテクニックのひとつ として、単語と数字ともうひとつの単語の組み合わせちうのがあり まんねん。"shark6cider" や "jump3joy" といったもんや。 これやと、dictionary crack の検索空間が巨大になるさかい、 見つけるんは難しなるでっしゃろ。そやけど、ここに挙げた例を そのまんま使うことはお止めおくんなはれ。クラッカーはこの文書を 読んだあとで、上記のパスワードをすでに検索辞書のなかに 追加してんかもしれへんからや。
では、第三のケースを見てみまひょ。
snark:~$ ls -ld ~ drwxr-xr-x 89 esr users 9216 Jun 27 11:29 /home2/esr snark:~$ |
上記のファイルはディレクトリや("d" ちう文字がパーミッション の最初の位置にあることに用心をしておくんなはれ)。こら、esr のみが 書き込み権限を持ち、どなたはんでも読み出しと実行ができるゆうことが 分かる思うで。
読み出しのパーミッションがあるんで、そのディレクトリ内に何があるんか 表示するっちうことが可能になっとりまんねん。すなわち、そのディレクトリに含まれる ファイルやディレクトリ名の一覧を見ることができるゆうことや。 書き込みパーミッションがあると、そのディレクトリ内にファイルを 作成したり、削除したりするっちうことができまんねん。ディレクトリには、 ファイルとサブディレクトリの名称の一覧が含まれとるちうのを 思い出すんやったら、こないなルールには納得がいく思うで。
ディレクトリの実行パーミッションちうんは、そのディレクトリを経由して それ以下の階層にあるファイルやディレクトリを開くことができるゆう ことを意味してるんや。実際には、こら、ディレクトリ内の i-node に アクセスするパーミッションを与えとりまんねん。ディレクトリから 実行権限をぜええんぶひとつのこらず外してまうと、そのディレクトリが使えなくなって しまいまんねん。
実行権限はみなの人に与えるが読み出し権限は制限してんディレクトリ ちうのをときどき見はる思うで。こら、どないなユーザでも そのディレクトリ以下にあるファイルやディレクトリに到達するっちうことが できるのやが、それらの正確な名前をしっとる場合やないとあかんと いうことを意味します(ゴチャゴチャゆうとる場合やあれへん、要は、ディレクトリを一覧表示するっちうことが でけへんわけや)。
あるディレクトリの読み出し・書き込み・実行のパーミッションは、そのディレクトリ 以下にあるファイルやディレクトリのパーミッションとは独立の問題であるちう ことを覚えといておくんなはれ。特に、ディレクトリの書き込みパーミッション ちうんは、そこに新規のファイルを作成したり、既存のファイルを削除したり できる権限を意味するもんなんやし、そこにある既存のファイルへの 書き込み権限をなあんもせんとホッタラかしといても与えるもんやおまへん。
ケツに、ログインプログラム自体のパーミッションを見てみまひょ。
snark:~$ ls -l /bin/login -rwsr-xr-x 1 root bin 20164 Apr 17 12:57 /bin/login |
こら、システムコマンドによう見られはるパーミッションや。そやけど、ここの 's' ちう、所有者実行 bit (owner-execute bit) の設定ちうんは例外的 や。こら、'set-user-id' もしくは setuid bit と呼ばれる特別なパーミッションを表してるんや。
setuid bit ちうんは、一般に、特殊なプログラムに対して付与される パーミッションや。すなわち、root の権限を、一定の制限付きで一般ユーザにも 与える必要のあるプログラムがそれに該当しまっせ。setuid bit が 実行プログラムにセットされた場合、ユーザは、そのプログラムファイルの所有者と 同じ権限を行使できるようになるちうワケやが、他方で、ユーザがその所有者であるか 否かに関らへんし、そのプログラムはユーザ自身の名で実行されるゆうもんや。
root アカウント自体と同様、setuid されたプログラムも便器...おっとちゃうわ、便利ではおますが、 危険や root が所有者である setuid されたプログラムをカンペキに破壊したり 変更したりできるひとやったらだれそやけど、そのプログラムを使うて root 権限 を持ったシェルを起動するっちうことができるさかいや。それやから、大部分の Unix システムでは、何ぞ書き込むためにそのファイルを開いた時点で、 setuid bit がなあんもせんとホッタラかしといてもチャラになるようになっとりまんねん。Unix セキュリティ に対する攻撃のようけが、setuid プログラムをカンペキに破壊するために、setuid プログラムのバグを悪用したろおもておりますわ。したがちう、セキュリティ意識 を持っとるシステム管理者は、そないなプログラムに特に慎重になって いて、出来よったばっかりの(バグが除去されておらへん)プログラムはインストール したがらしまへん。
これまでパーミッションについて解説したことの詳細に関して、いくつか 重要なことがおます。すなわち、所有グループとパーミッションは、 そのファイルが作成された際にどないな方法で割り当てられはるんか ちうことや。ユーザは複数のグループのメンバーとなることが できるさかい、このグループの割り当ては問題ではあんねんけど、 そのひとつは、(/etc/passwd ファイル内の そのユーザのエントリで指定されとる)ユーザの デフォルトグループ (default group) が割り当てられ、ユーザによって 作成されたファイルは、通常そのグループが所有するっちうことになるんですわ。
パーミッション bit のアタマ bit の話は、もうすこし複雑や。なんらかの ファイルの作成を伴うプログラムは、通常、そのファイルの初期設定として のパーミッションを指定しまっせ。せやけどダンさん、それらは、 umask と呼ばれるユーザの環境変数によって変更されてしまいまんねん。 umask は、ファイルを作成する際にどのパーミッション bit をチャラにするかを指定するもんや。最も一般的な値なんやし、 たいていのシステム上のデフォルトとなっとるんは、------w- もしくは、 002 や。こら、どなたはんでも書き込みが出来よるちう権限をチャラにする もんや。これに関する詳しい説明は、読者の shell の man ページ にある umask コマンドに関する文書を御覧おくんなはれ。
ディレクトリグループの初期設定ちうのも、やや複雑や。Unix のなかには、 新規ディレクトリのグループには、それを作成したユーザのデフォルトグループ を当てんねんもんがおます(こら、System V 系の慣習や)。それ以外にも、 作成されたディレクトリの親ディレクトリの所有グループが割り当てられはる もんもおます(こら、BSD の慣習や)。Linux を含む現在の Unix のなかには、 set-group-ID をそのディレクトリに設定する(chmod g+s)ことによって、 後者のように動作するよう設定できるもんがおます。
よりどエライ昔、ファイルシステムはどエライ繊細であるちうことを漠然とゆうたんやが、 いまの時点では、ファイルに到達するには、ディレクトリと i-node を 参照しながら、どんだけ長いか分からへん連鎖を辿っていかなならへん ちうことが分かっとる思うで。では、ハードディスクに不良箇所 が発生した場合、こらどないなるでっしゃろか?
幸運に恵まれれば、ファイルデータのいくつかをダメにするだけで済みまんねん。 そうやない場合は、ディレクトリ構造や i-node 番号をカンペキに破壊してもうて、 システム内の特定のサブツリー以下がお釈迦になってまうかもしれしまへん。 さらに、ファイル構造自体が壊れてもうて、雑多なアクセスが 同一のディスクブロックや i-node に集中してしもたりするかも しれしまへん。そないな不具合は、通常の操作を続けとると、 どんどん広がっていて、最初の不良箇所にあったデータが システム全体にばら撒かれてまうかもしれしまへん。
幸いにも、この手の偶発事故は、ディスクのハードウェアの信頼性が高まった ことで、ほとんど生じなくなったんやが、ほんでも、やっぱり、Unix では、 定期的にファイルシステムの整合性チェックを行なちう、なあんも異常があらへん ことを確認する必要性がおます。現在の Unix は、個々のパーティション に対して、起動時のマウント直前にすばやく整合性のチェックを行うように なっとりまんねん。何回かにいっぺんは、もう数分時間がかかる完全なチェックを 行なう仕組みになっとりまんねん。
こないなことを読んで、Unix は恐ろしく複雑で不具合が起きやすいかのよう に思えたやったら、こう考えておくんなはれ。これらの起動時のチェックは、 通常はようあるんやうな問題を検出・修正して、それがホンマの大惨事に いたるのを防いどるのや。こないな機能を持たへん他のオペ レーティングシステムの場合、確かに起動は高速になるんやが、実際に 手動で復旧せなやったらなくなりよった時は、問題がこじれてもうて 深刻な状態になっとることがおます(とはいえ、こら、そもそも Norton Utility かそれに類するツールを持っとる場合やけど、そやけどアンタ...）。
きょうびの Unix の設計上のトレンドのひとつに、 journalling file systems がおます。 こら、ディスクとのやり取りを調整するっちうことで、常に整合性が 保たれることを保証し、システムが起動するっちうときに復旧が 可能になるようにする仕組みや。こら、起動時の整合性チェックを ごっつう高速化するっちうことができまんねん。