西田 亙の本：GNU 開発ツール -- hello.c から a.out が誕生するまで --
Categories Books | Hard | Hardware | Linux | MCU | Misc | Publish | Radio | Repository | Thoughts | Time | UNIX | Writing | プロフィール
本ページ掲載後、BSD Magazine にも寄稿されていた神戸(かんべ)様から、以下のような貴重なご指摘を頂きました。ご本人より転載の許可を頂きましたので、以下ご指摘頂いた点を掲載いたします。
「BSD vs Linux」という項で「*BSDが守り続けている古き良き文化」として /sbin/init のアクセス権が挙げられています。これは、どこまで古き良き 文化なのかは議論の余地があると思います。 ふるーい 4.3BSD あたりでは /etc/init でしたが、アクセス権については 何も考えられておらず、自身がroot権限で実行されたかどうかもチェックして いませんでした。研究室の学部生が /etc/init を通常のユーザとして実行して 大変なことが起きたことを覚えています。 0500としたのは、4.4BSDか4.4BSD-liteの頃のようで、さらにシステムレベル の変更不可能なファイル・フラッグがセットされていました。 片や、NetBSDあたりでは 0555 だったり、FreeBSDでは 6.1リリースの後に 0500から0555にされたり、しています。また、FreeBSDやNetBSDでは/sbin以下 と言えども既にstatic linkされていません。 時代は変わるという面もありますが、/sbin/initのアクセス権やstatic link されていることは、「古き良き文化」の例としては適切ではなくなっていると思います。 |OpenBSDではルートのみ起動できるパーミッションが設定されています。 |しかも、WriteフラグはOFFになっているため、このままではルートすら |ファイル削除・変更はできないようになっています。 と、ありますが、 o ファイルの削除は /sbin/init のパーミッションではなく、/sbinのパーミッション次第です。 rm(1)は書き込めないファイルの削除に対してウォーニングを表示して確認を求めてきますが、 これはコマンド・レベルのことであってシステムコールのレベルでは何らの制限なく削除はできます。 o 特権ユーザrootについては、書き込み権がないことに、あまり意味はありません。 例えパーミッションが 0 であっても、rootは読み書きができてしまいます。 従いまして、上記の /sbin/init のパーミッションからくる制限については、誤った記述となります。
要約しますと、
私が手元で稼働させている BSD は OpenBSD のみなのですが、ファイル/ディレクトリ・パーミッションや sbin ディレクトリ・コマンド群のリンク方法は NetBSD/FreeBSD 間で共通なのだと勝手に思いこんでおりました。下調べが不十分なままに掲載してしまい、申し訳ありません。下記の文章中、*BSD と表記していた箇所はすべて OpenBSD に変更いたしました。
/sbin/init のパーミッションフラグに関しても、ファイル自身の write フラグが削除に影響を与えるかのような表記になっており、失礼いたしました。該当箇所については、修正しています。
また、スーパーユーザの場合、ファイル削除に際してディレクトリの write フラグが無視されるというご指摘に関しては、私自身認識がありませんでした。パーミッションフラグについては、私も一度腰を据えて調べる必要があると考えていたのですが、良い機会なので別途記事を執筆してみることにしました。興味のあるかたは、こちらをご覧ください。
貴重な情報とご指摘を頂きました神戸様に、この場を借りてお礼申し上げます。
Computer Architecture Series は、ソフトウェアとハードウェアの両面からコンピュータを理解することをテーマに置いていますが、この時必要になるものが開発環境です。1970-1980年代とはことなり、現在は誰もが無料で PC-UNIX 上の優れた開発環境を享受することが可能になっていますが、本シリーズは Debian GNU/Linux Sarge をベースに解説を行うこととしました。
当初、OpenBSD を候補としていた時もあったのですが、CPLD/FPGA デザインツールである Xilinx ISE WebPACK に代表されるように、PC-UNIX をターゲットとしたメーカー製ツールは、通常 Linux のみをサポートしていること。x86 アーキテクチャに関しては、Linux kernel 2.4 は教材としてなかなか面白い素材であること。何よりもリソースが豊富であること、などからカーネルには Linux を選択しました。
ただし、Linux はカーネルを中心に据えた開発形態を取っており、ライブラリやシステムツールに関しては、他人(GNU)任せとなっています。結果として、ソースツリーやヘッダーファイルは "継ぎはぎだらけ" の状態となり、システム全体を把握するためには大変な困難を伴うことになります。
これに対して、OpenBSD ではカーネルだけでなくライブラリやユーザスペースツール、ドキュメントも "一枚岩" として開発されます。両者は、全く対照的な存在と言えますが、残念なことに OpenBSD が守り続けている古き良き文化は、Linux ユーザにはあまり知られていないようです。
例えば、ファイルパーミッションの設定ひとつをとっても、OpenBSD と Linux 界では大きな違いがあります。カーネル起動後に最初に実行される /sbin/init プログラムを見てみると、OpenBSD では次のようになっています。
OpenBSD $ ls -l /sbin/init -r-x------ 1 root bin 210432 Mar 3 2006 /sbin/init OpenBSD $ sudo ldd /sbin/init /sbin/init: ldd: /sbin/init: not a dynamic executable
ファイルパーミッションに注目してください。/sbin/init は別名 swapper と呼ばれる全てのプロセスの親となるプログラムですが、当然のことながらシステム起動時に一度実行されるだけなので、OpenBSD ではルートのみ起動できるパーミッションが設定されています。
次のコマンドラインでは、ldd コマンドで /sbin/init の外部依存状況をチェックしていますが、「動的リンクによる実行可能ファイルではない」と表示されていることから、/sbin/init は静的リンクにより作成されていることが分かります(ファイルサイズに注目)。なお、ルート以外には読み出しが許可されていないため、一般ユーザが ldd コマンドで /sbin/init を解析することはできず、実行例では sudo を使用しています。
次に、Debian GNU/Linux Sarge の場合です。
Debian $ ls -l /sbin/init
-rwxr-xr-x 1 root root 31432 2005-01-04 22:43 /sbin/init
Debian $ ldd /sbin/init
libc.so.6 => /lib/libc.so.6 (0x4001b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Debian ではルートのみならず、全てのユーザが参照・実行可能なパーミッションが設定されています。
また、ldd コマンドの結果は(OpenBSD からすると、一般ユーザが参照できること自体に問題があるのですが) /sbin/init が動的リンクで作成されていることを意味しています(ファイルサイズも OpenBSD の1/7)。
なぜ、OpenBSD はディスク資源を７倍も消費する静的リンクでシステムツールをビルドしているのでしょうか？この理由を知るためには、動的リンクの仕組みと脆弱性を理解する必要があります。
Computer Architecture Series では、基本技術の解説を行いながら、システム管理上重要な点に関しては、OpenBSD と Linux の違いとその背景についても言及しています。
Linux ディストリビューションとしては、長年の実績と充実したパッケージおよび付属公開情報を持つ、Debian GNU/Linux が "教材" として最もふさわしいと私は考えています。
最近では、Linux From Scratch (LFS) という、全ての Linux 環境を我が手で再構築するという、野心的なプロジェクトがありますが、恐らく多くのユーザーは "手順の繰り返し" で終わっているのではないでしょうか。内容を理解するためには、対象があまりに複雑すぎるように思います。
かくいう私も、一時期学習用のオリジナル・ディストリビューションを準備していたことがあるのですが、安定して長期間に運用することを考えると、開発環境と実験用環境は切り分けた方が良いだろうと判断し、Debian GNU/Linux を選択しました。Linux カーネルを用いたサーバー管理を行うのであれば、Debian に優るものはないように思います。
また、教育的観点から見ても Debian は優れた Linux ディストリビューションと考えられます。向学心に燃える Linux 初心者であれば、システムに用意された /etc ディレクトリの設定ファイルや、各種コマンドが一体どこからやってきたのか、気になることでしょう。Debian であれば優れたパッケージ情報により、どこまでも深く潜っていくことができます。
例えば、GNU 開発ツールの第６章でも登場する ldconfig コマンドを見てみましょう。このコマンドは、共有ライブラリを管理する ld.so.cache ファイル再構築用の管理コマンドです。OpenBSD とはことなり、動的リンクに全面的に依存する Linux ディストリビューションでは、極めて重要なコマンドのひとつであり、システム管理者であればその使用方法と意義について熟知しておく必要があります。
ldconfig がどのパッケージに由来するかは、Debian パッケージ の下部に用意されている "パッケージの内容を検索" を利用します。ここで ldconfig と入力すると、sbin/ldconfig は base セクションの libc6 パッケージに由来することが分かります。
libc6 のリンクをクリックすると、同パッケージの詳細内容が表示されます。ここまで来ると、libc6 パッケージに含まれる他のファイル群が気になるのが人情というものですが、この場合は i386 アーキテクチャの "list of filesをクリック" してください。絶対パスのアルファベット順に、1994個ものファイル一覧を得ることができます。
最後に、「ソースリストを拝みたい」という野望がムラムラと湧き上がる方もおられることでしょう。この場合は、libc6 パッケージの最下段に用意されている Source Package フィールドに記載されている、オリジナルのソースターボールおよび Debian 用のパッチファイルが役立ちます(Debian ユーザであれば、コマンドライン上で sudo apt-get source libc6 と入力するだけで、自動展開されます)。
様々なツールやパッケージのソースファイルはネット中に散らばっているため、オリジナルの最新版を探索するだけでも結構な労力を必要とします。また、発見したものの配布元が閉鎖されていることもしばしばです。こんな時は、Debian パッケージが大いに役立つことでしょう。
最後に、今年の12月には次期バージョンの etch が公開予定であるにもかかわらず、なぜ sarge なのかという点ですが、これについては日を改めてご説明したいと思います。
上記の記事を執筆している最中(24:00前後だったと思いますが)、本サイトへのアクセスがフリーズしてしまいました。いつもの無線ルーターの不調かと思い、ネットワークのチェック代わりに /.J を表示してビックリ。「なんじゃこりゃ〜」。
早速、米国のサーバーにログインし、netstat でチェックすると 500 近いコネクションが張られています。「お〜まいがー！」httpd.conf 中の MPM (Multi Processing Module) の設定はデフォルトで運用していたため、慌てて修正＆ restart し、間もなく復旧しました。多数の方にご迷惑をおかけしてしまい、誠に申し訳ありません。この場を借りて、お詫び申し上げます。
北は北海道から、南は沖縄まで各地の方々から予約を頂いている上に、ネット上でもご紹介頂き、ありがたい限りです。今夜はどちらへ足を向けて寝れば良いのでしょうか・・。