目次
Cygwin とは Windows 上における Linux 的な環境です。
Cygwin は基本的な
POSIX (Portable Operating System Interface)
システムコールを提供するエミュレーション層である
DLL(cygwin1.dll)と、
Linux 的なルック & フィールを提供する様々なツールの集合から構成されています。
Cygwin DLL は Windows 95 以降の x86 版 Windows 上で動作します。
Cygwin をインストールすれば、ユーザは数多くの標準的な
UNIX ユーティリティを利用することが出来ます。これらのツールは bash
のような Cygwin が提供するシェル上で利用することも、
Windows のコマンドプロンプト上で利用することも出来ます。
加えて、プログラマは 標準的な Microsoft の Win32 API 及び
Cygwin API を利用して、Win32 のコンソールアプリケーション又は
GUI アプリケーションを作成することが出来ます。結果として、数多くの重要な
UNIX プログラムを大規模なソースコードの修正なしに容易に移植することが出来ます。
(Cygwin の配布物中に含まれる開発ツールに入っているパッケージを含んだ)殆どの
GNU ソフトウエアの configure とビルドもこの対象となります。
はい。幾つかは GNU
のソフトウェア(gcc、gas、ld、など)であり、幾つかは標準的な
X11 ライセンス
によって保護されています。パブリックドメインなものもあれば、Red Hat が書いて
GNU 一般公有使用許諾契約書
(GPL)の元に置いたものもあります。シェアウェアはありません。
これを使用するために誰かにお金を支払う必要はありませんが、これらのツールを使用する上で
GNU GPLがどのような影響を与えるかについての詳細な情報を、FAQ
の著作権の章を読んで確認しなければなりません。もし Cygwin
を使って商用(GPL でない)アプリケーションを移植しようと考えているのであれば、Cygwin
の商用ライセンスが必要になるかもしれません。
商用ライセンスについての詳細な情報については、
http://www.redhat.com/software/tools/cygwin/.
を参照して下さい。
ネイティブ Win32 版 の GNUPro の顧客は、
通常の窓口を通じてバグレポートを送ったり質問したりすることが出来ます。
その他の質問は全て、このプロジェクトのメーリングリストである
<cygwin@cygwin.com> に送ってください。
Cygwin のより完全な歴史については、Geoffrey J. Noer による 1998 年の論文 「Cygwin32: A Free Win32 Porting Layer for UNIXョ Applications」を参照して下さい。これは 第 2 回 USENIX Windows NT シンポジウム オンライン議事録 から手に入ります。
Cygwin の開発は Cygnus Solutions(現在は Red Hat Software の一部門となっています)
によって 1995 年から始められました。まず、開発ツール(gcc、
gdb、gas など)の強化が行われました。
これによって Win32 ネイティブオブジェクトファイルの生成と解釈が出来るようになりました。
次の仕事はツールを Windows NT/95 に移植することでした。ソースの大部分を Win32 API
の文脈で動作するように書き換えることでも出来たでしょうが、
その方法では個々のツール全てに対して膨大な時間を費やすことになります。
その代わりに我々は、共有ライブラリ(Cygwin DLL)を書くという全く異なったアプローチを取ることにしました。
このライブラリは UNIX 風の環境に必要な機能
(fork、spawn、signals、
select、socketsなど)のうち、
Win32 API に欠けているものを追加します。
我々はこの新しいインタフェースを Cygwin API と呼んでいます。
このライブラリが作成された後は、
UNIX 上のクロスコンパイラを使ってこのライブラリをリンクし、
動作する Win32 ツールをビルドすることが可能になりました。
この時点で我々は、Windows 95/NT 上で自分自身を再構築可能なネイティブツールを作成する、という目標を達成しました(これはよく「セルフホスティング」と呼ばれます)。 95 にも NT にも UNIX 上の標準的なユーザツール(fileutils、textutils、 bash などなど)は付属していないので、私たちは Cygwin API と共に動作する同様の GNU ツールを手に入れる必要がありました。 それまで、これらのツールの殆どは Windows 専用にビルドされていたため、 configure スクリプトをクロスコンパイルできるように修正する必要がありました。 その変更以外にも、ごく僅かですがソースレベルの変更が必要でした。 bash が開発ツールやユーザツールと共に正しく動作すれば、 Windows 95 も NT も、GNU configure のメカニズムから見れば UNIX の一種のように見えます。セルフホスティングは 1996 年 10 月にリリースされた beta 17.1 以降で達成されました。
完全な Cygwin ツールセットは、単一の巨大な存在としてのみインストール可能でした。
2000 年 4 月に、プロジェクトは
新しい Cygwin Net Release をアナウンスしました。
Net Release では、パッケージを個々にインストール及びアップデートするためのネイティブ
Win32 プログラムである setup.exe が提供されています。
Cygwin DLL と setup.exe は、今も継続して開発されています。
もし UNIX の世界に初めて足を踏み入れたのであれば、 この世界を理解することは困難であるということにまず気付くでしょう。 このガイドは包括的なものではありませんから、インターネット上で利用可能な各種のリソースを利用して UNIX の基本について理解することをお勧めします(「UNIX 基本」或いは「UNIX 入門」などで検索してみて下さい)。
基本的な Cygwin 環境をインストールするには
setup.exe プログラムを実行し、各ページで
Next をクリックします。
デフォルトの設定は多くのユーザにとって適切なものです。
各オプションが何を意味するのかについてより深く知りたければ、
項2.1. 「インターネットセットアップ」 を参照して下さい。
Cygwin のパッケージをインストール、或いはアップデートしたいときは、常に
setup.exe を利用して下さい。
Cygwin を特別な目的でインストールするのであれば、setup.exe
を利用して必要なツールをインストールします。
例えば、C++ のプログラムをコンパイルしたければ gcc-g++
パッケージと、恐らくは nano のようなテキストエディタが必要でしょう。
setup.exe を実行し、パッケージインストール画面でカテゴリとパッケージをクリックすれば、
インストール或いはアップデートの対象とするものを選択出来ます。
もう一つの選択肢は、All カテゴリの
Default フィールドをクリックして Install
へと変更し、全てのパッケージをインストールするというものです。しかし、この方法では何百 MB
ものソフトウェアがあなたのコンピュータにダウンロード及びインストールされるということに注意して下さい。
最良のプランはおそらく、個別のカテゴリをクリックしてカテゴリ全体、或いはカテゴリ中の必要なパッケージを選んでインストールすることでしょう。
Windows 上での経験を持つ開発者は、Microsoft の Win32 API を利用するコンソール実行形式、或いは
GUI の実行形式を作成するためのツールが揃っていることに気がつくでしょう。
dlltool ユーティリティは Windows のダイナミックリンクライブラリ
(DLL)を作成するために使われます。リソースコンパイラとして
windres も提供されています。全てのツールは
Microsoft のコマンドプロンプトから利用可能です。この場合、通常の
Windows パス名も完全にサポートされます。
強力なコマンドライン環境に飢えている経験豊富な UNIX の利用者は、 Cygwin を存分に楽しむことが出来るでしょう。幾つかのワークアラウンドが含まれているため、 Cygwin の動作は大部分の UNIX 系オペレーティングシステムとは異なっていることに注意して下さい。 更なる詳細については、項3.8. 「Cygwin を Windows と共に効果的に使う」 に記述されています。
グラフィカルな setup.exe プログラムを利用することによって、
いつでも Cygwin のパッケージをアップデート、或いはインストールすることが可能です。
デフォルトでは setup.exe は最小限のパッケージしかインストールしませんので、
好みのユーティリティをパッケージ選択画面から選んで下さい。
特定のツールを探すには、Cygwin の Web サイトにある
Setup Package Search が利用出来ます。
setup.exe の各オプションが何を意味するかについての更なる詳細については、
項2.1. 「インターネットセットアップ」 を参照して下さい。
もう一つの選択肢は、All カテゴリの
Default フィールドをクリックして Install
へと変更し、全てのパッケージをインストールするというものです。しかし、この方法では何百 MB
ものソフトウェアがあなたのコンピュータにダウンロード及びインストールされるということに注意して下さい。
最良のプランはおそらく、個別のカテゴリをクリックしてカテゴリ全体、或いはカテゴリ中の必要なパッケージを選んでインストールすることでしょう。
UNIX での経験を持つ開発者は、今まで慣れ親しんできたユーティリティ群(UNIX シェルを含む)を見つけることが出来るでしょう。 コンパイラツールは、多くの人々が既に UNIX 上で使ったであろうと思われる、Windows ホスト上に唯一移植された標準の GNU コンパイラです。UNIX ソフトウェアを Windows NT または 9x に移植したいと考えているプログラマには、Cygwin ライブラリが ソースコードに対する最小の変更だけで UNIX パッケージを移植出来る簡単な方法を提供しているということことが分かるでしょう。
Cygwin DLL をリンクしたバイナリが実行されると、Cygwin DLL はアプリケーションのテキストセグメントをロードします。 Cygwin DLL の元で動作する全てのプロセスがアクセスすることになる UNIX カーネルをエミュレートするために、Cygwin DLL はまず、 DLL の個々のインスタンスを使用するプロセスがアクセス可能な共有メモリ領域を作成します。 特に、オープンされたファイルのディスクリプタの保持と、 fork 及び exec の補助のために使われます。 全てのプロセスは、追加された共有メモリ領域中にプロセス ID、ユーザ ID、 シグナルマスク、そして他のプロセス独自の情報を格納するための per_process 構造をも保持します。
Cygwin DLL は Win32 API を使用して実装されており、 全ての Win32 ホスト上で動作します。 プロセスは標準 Win32 サブシステムの元で動作するので、 これらのプロセスは Win32 API 呼び出しと同様に Cygwin が提供する UNIX 互換の呼び出しを扱うことが出来ます。 これはプログラマに対し、Win32 API を使用して作られたプログラム構造のデザインに完全なる柔軟性を与えます。 例えば、彼らは Cygwin を使用することによって UNIX バックエンド上に、 Win32 API 呼び出しを使用した Win32 特有の GUI を書くことが出来るのです。
開発工程の初期に、我々はそれが不可能な場合、又は Win32 プラットフォーム上でのツールの使い勝手を極めて悪くしてしまう場合、 POSIX.1 のような既存の UNIX 標準の存在に対して厳格に忠実である必要はないのではないかという、重要な設計の議論を行いました。 多くの場合は、ある環境変数によってデフォルトの振る舞いを上書きしたり、 標準への準拠を強制出来るようにしました。
Cygwin を実装する上では、Windows 95 と Windows 98 はその差を安全に無視出来る程度に、お互い十分に似ています。 Windows NT は極端に異なったオペレーティングシステムです。 そのため、適切に動作出来るよう、 Cygwin DLL はロード時にどちらのオペレーティングシステム上で使用されているのかを常にチェックします。
幾つかの場合、Win32 API は歴史的な理由によってのみ差異が存在します。 この場合、同様の基本的な機能は Windows 9x と NT で利用可能ですが、 その機能を得るために使われる方法は異なっています。 些細な例を挙げましょう。我々の uname の実装においては、 ライブラリは Windows 9x の元ではプロセッサのタイプを得るために sysinfo.dwProcessorType 構造体メンバを調査します。 このフィールドは NT ではサポートされておらず、 sysinfo.wProcessorLevel と呼ばれるオペレーティングシステム独自の構造体メンバに格納されています。
NT と 9x の間におけるその他の違いは、その生い立ちによるものです。 最も良い例は、セキュリティモデルは NT のみが備えているということでしょう。
Windows NT はアクセス制御リスト(ACL)をベースにした、 洗練されたセキュリティモデルを備えています。 デフォルトでは、Cygwin は Win32 ファイルの所有権とパーミッションを、 より標準的な古い UNIX のモデルに対応付けます。 Cygwin バージョン 1.1 は、新しいバージョンの Solaris が使用しているシステムコールによって ACL のサポートを取り入れています。 「ntsec」機能と共に使用されるこの機能については別章で説明されています。 chmod 呼び出しは、Win32 の同等な機能から UNIX スタイルのパーミッションを割り当てます。 多くのプログラムは /etc/passwd と /etc/group ファイルの存在を仮定しているため、 オペレーティングシステムによって提供されるユーザとグループの情報からこれらのファイルを構築するユーティリティが提供されています。
Windows NT 環境下では、administrator はファイルの chown が出来ます。 Cygwin バージョン 1.1.2 以来、setuid のコンセプト又は API 呼び出しのメカニズムはありません。 バージョン 1.1.3 では、Cygwin は Windows NT/2000 環境下での実 UID 及び実効 UID の設定メカニズムを取り入れました。 これについては ntsec の章で説明されています。
Windows 9x 環境下では、この状況は相当に異なるものとなります。 セキュリティモデルが準備されていないため、Cygwin は ファイルがデフォルトのユーザ ID とグループ ID によって所有されているように見せかけることで、 ファイルの所有権を偽装します。 NT 環境下では、ファイルパーミッションはファイルの読み / 書き / 実行状態を調べることによって決定することが出来ます。 Windows 9x 環境下での chown 呼び出しは、 実装されていないというエラーを返すのではなく、 何らの処理をも行わずに直ちに成功を返します。 ファイルの所有権という概念が全く存在しない場合、 全てのユーザはファイルを一緒に所有していることになるので、 これは本質的に適切です。
Cygwin プロセスに関する情報を蓄えた共有メモリを使用する「カーネル」 の密接な関係に関する議論は重要です。 それらの領域にはまだ何らの保護もなされていないため、 Cygwin プロセスが予期しない動作を起こすように、 悪意のあるユーザがそれを書き換えることが原則的に可能です。 (オペレーティングシステムによるセキュリティが欠けているがための) Windows 9x 環境下での新しい問題ではなく、 Windows NT 環境下でもセキュリティホールとなり得るものです。 なぜなら、あるユーザによって実行された Cygwin プログラムに対し、 他のユーザが通常の Windows NT のプログラムでは不可能な方法によって共有メモリ情報を変更することにより、 そのプログラムに影響を与えることが出来るからです。 このため、高いセキュリティが要求されるアプリケーションにおいて Cygwin を使用することは適切ではありません。 実際のところ、これはライブラリの大部分の用途に対しては大きな問題とはなりませんが。
Cygwin は、 ディレクトリの区切りとしてスラッシュあるいはバックスラッシュを使用する、 Win32 と POSIX の両方のパス形式をサポートしています。 DLL が受け取ったパスは必要に応じて Win32 パスから POSIX パスへと変換されます。結果として、ライブラリはファイルシステムが POSIX 準拠のものであると考え、Win32 API 関数を呼び出すときは常にパスを Win32 パスへと変換します。UNC パス名(二つのスラッシュから始まる) もサポートされています。
Windows ファイルシステム空間にあるこの POSIX ビューのレイアウトは、Windows レジストリ中に蓄えられます。 デフォルトでは、スラッシュ(「/」)ディレクトリはシステムパーティションを示しますが、 これは Cygwin の mount ユーティリティによって簡単に変更出来ます。 スラッシュパーティションの選択に加えて、このユーティリティは任意の Win32 パスを POSIX ファイルシステム空間へとマウントします。多くの人々は、各ドライブ文字をスラッシュパーティションへと割り当てる(例えば、C:\ を /c に、D:\ を /d に、など)ためにこのユーティリティを使用しています。
Cygwin DLL は、 Win32 のパス又はパスのリストから POSIX パスへの変換あるいはその逆を行う外部プログラムによって使用される、 様々な Cygwin 独自の関数をエクスポートしています。 シェルスクリプトや Makefile はこれらの関数を直接呼び出すことは出来ません。 代わりに、それらの中では Cygwin に付属する cygpath ユーティリティを実行することによって、同様のパス変換が行えます。
Win32 のファイルシステムは大文字小文字の区別を保存しますが、 大文字小文字の区別は行いません。 Cygwin は現在のところ、大文字小文字の区別はサポートしていません。 なぜなら、実際には大文字小文字の区別に頼っている UNIX プログラムはごく僅かだからです。 大文字小文字の区別のサポートによってファイル名を押し延ばすことが出来ますが、 これはライブラリに対して不要なオーバーヘッドを発生させ、 それらのファイルに対する非 Cygwin アプリケーションのアクセスをより難しいものにしてしまうでしょう。
シンボリックリンクは、リンク位置を示すパスに続くマジッククッキーを含んだファイルによってエミュレートされます。 それらのファイルにはシステム属性が付与されます。 システム属性を持つファイルだけが、 そのファイルがシンボリックリンクであるか、 そうでないかの判定のために用いられるからです。 ハードリンクは Windows NT 環境上の NTFS ファイルシステムでは完全にサポートされています。FAT ファイルシステムでは、 link 呼び出しは単純にファイルのコピーを行いますが、 この方針は多くの場合問題なく動きます。
ファイルに対する i ノード番号は、完全な Win32 パスをハッシュして計算されます。stat 呼び出しによって生成される i ノード番号は、dirent 構造体中の d_ino に格納される値と常に合致します。 この方法で生成される番号はユニークである保証はない、ということに注意して下さい。 しかし重複した i ノード番号が生成される可能性は低いため、 このことが重大な問題となったことはありません。
chroot はリリース 1.1.3 からサポートされました。chroot は本来、Windows ではサポートされていないという点に注意して下さい。これは幾つかの制限が存在することを意味します。第一に、chroot 呼び出しは特権呼び出しではなく、個々のユーザが呼び出すことが可能です。 第二に、chroot 環境はネイティブの Windows プロセスに対して安全ではありません。 chroot 環境をサポートしたいのであれば、例えば、制限付きのアクセスを備えた匿名 FTP をサポートしたいのであれば、ネイティブの Cygwin アプリケーションだけが chroot 環境の内部にアクセス出来るように注意する必要があります。 アプリケーションがファイルシステムに対するアクセスに Cygwin の POSIX API だけを使用するのであれば、そのアプリケーションは意図した通りに制限されます。 これは POSIX パスだけでなく、Win32 パス(ドライブ文字とバックスラッシュを含む)と CIFS パス(//server/share 又は \\server\share)もまた含まれます。
テキストエディタのような他の Win32 プログラムとの相互運用性は、 開発ツールの移植を成功させるためには重要でした。 かつての DOS をホストとした toolchain からアップグレードした Red Hat の顧客の多くは、 Win32 をホストとした新しい toolchain でも、 従来の開発ソースが利用できることを期待していたからです。
不幸なことに、テキストファイルの各行の終端文字は UNIX と Win32 では異なっています。 その結果として、テキストモードで読み込むときは、Cygwin は速やかに復帰改行を一つの改行へと変換しなければなりません。
この対応策は、テキストとバイナリのモードは等しいと明言している POSIX 標準に対する違反の代償として、互換性に対する要求に注意を向けたものです。 その結果、テキストファイルに対する lseek を行うプロセスは、 ファイル中の正確な位置を示す値として読み込んだバイト数を信頼することは出来ない、ということになります。 このため、CYGWIN 環境変数によってこの動作を変更することが出来ます。
我々は libc と数学関数の全てをスクラッチから書くよりも、 Red Hat が所有している既存の ANCI C ライブラリ「newlib」を Cygwin DLL の一部分として含めることを選びました。 Newlib は BSD から派生した ANCI C ライブラリであり、 それまでは組込みシステム開発時のクロスコンパイルにのみ使用されていました。
glob、regexp そして getopt ライブラリのような既存のフリーの実装を再利用することで、 かなりの作業量を減らすことが出来ました。 加えて、Cygwin では速度とサイズの両面でバランスが取れた、 Doug Lea によるフリーの malloc の実装が使われています。 Cygwin DLL はエクスポート関数へのポインタを使用して malloc 呼び出しを行います。これによって、 もし望むのであれば、Cygwin のプロセスは自前の malloc を用意することが可能となっています。
Cygwin での fork 呼び出しは、 Win32 API の最上位に対してうまく割り当てることが出来ないという点で、 特に興味深いものです。 そのため、この呼び出しを正しく実装することはたいへん難しい作業です。 現在、Cygwin の fork は初期の UNIX でよく使用されたような、 non-copy-on-write 実装を用いています。
親プロセスが子プロセスを fork する際に最初に発生する作業は、 親プロセスが子プロセスのために Cygwin のプロセステーブル内の領域を初期化するすることです。 それから、Win32 の CreateProcess 呼び出しを使用して、 サスペンド状態の子プロセスを作成します。 次に、親プロセスは自分自身のコンテキストを保持するために setjmp を呼び出し、Cygwin の共有メモリ領域 (Cygwin の全てのタスクの間で共有される) にこのコンテキストへのポインタを設定します。 そして、親プロセス自身のアドレス領域からサスペンド状態の子プロセスのアドレス 領域へとコピーすることで、 子プロセスの .data セクション及び .bss セクションを埋めます。 子プロセスのアドレス領域が初期化された後、 子プロセスが実行され、その間親プロセスはミューテックスを使用して待機します。 子プロセスは自分自身が fork されたことを知ると、保存されたジャンプバッファを使用して longjump します。 子プロセスは親プロセスが待機しているミューテックスをセットし、 もう一つのミューテックスをブロックします。 これは親プロセスに対して、 子プロセスが親プロセスのスタックとヒープをコピーし終わったことを知らせるシグナルとなり、 その後、親プロセスは子プロセスが待機していたミューテックスをリリースして fork 呼び出しから復帰します。 最後に、子プロセスは最後のミューテックスのブロックから復帰し、 共有領域を使用して渡されたメモリマップ済み領域を再生成して、 自分自身の fork から復帰します。
親プロセスと子プロセスの間で発生するコンテキストスイッチの数を減らすことで、 いかにして fork の実装を高速化するかということに対する幾つかのアイデアを得たとしても、 その後 fork はほぼ間違いなく常に Win32 の元では役に立たないものとなりました。 幸運なことに、多くの状況下では Cygwin が提供する spawn ファミリの呼び出しが、多少の作業だけで fork/exec の代わりを務めることが出来ます。これらの呼び出しは Win32 API の最上位に対して正しくマップされています。この結果として、 それらはより効果的なものとなりました。 fork の代わりに spawn 呼び出しを使うようにコンパイラのドライバプログラムを変更するという作業は些細な変更であり、 我々のテストではコンパイル速度が 20% から 30% も上昇しました。
しかしながら、spawn と exec にはそれぞれ独自の問題があります。 Win32 の元では実際の exec を行う方法が存在しないため、 Cygwin は独自のプロセス ID(PID)を考案しました。 この結果として、プロセスが複数の exec 呼び出しを実行した場合、 それらは一つの Cygwin PID に対して割り当てられた複数の Windows PID となります。幾つかの場合、これらの Win32 プロセスの個々のスタブが残ってしまい、 それらを呼び出した Cygwin プロセスの終了を待つことになります。
Cygwin のプロセスの開始時に、Cygwin DLL はシグナルハンドリング用に第二のスレッドを生成します。 このスレッドはシグナルをプロセスに渡すために使用される Windows イベントを待ち受けています。 プロセスに対してシグナルが送られた時点で、 このスレッドは自分自身が持つシグナルのビットマスクを調べ、 適切な方法でシグナル処理を行います。
実装における様々な複雑化は、 シグナルハンドラは実行プログラムとして同じアドレス空間で処理を行うという事実からきています。 直接の結論は、Cygwin システム関数は、 それを避けるための特別な処理がなければ中断され得るということです。 シグナルを送信する sig_send 関数が中断されるという事態を避けるため、 幾らかの長さに行きます(原文: We go to some lengths to prevent the sig_send function that sends signals from being interrupted.)。 プロセスが別のプロセスに対してシグナルを送る場合、 sig_send がシグナルの送信を完全に完了する前に中断されぬよう、 sig_send の周りにミューテックスが置かれます。
プロセスが自分自身に対してシグナルを送る場合、 ミューテックスの代わりにセマフォ及びイベントのペアを使用します。 sig_send はイベントによって開始され、 そのシグナルを処理するシグナルハンドラに立てられたセマフォをインクリメントします。 シグナルが処理されると、シグナルハンドラによっては既に実行されたイベントをシグナル状態にします。 このプロセスは POSIX によって要求されているプロセス間 (intraprocess)シグナル同期を管理します。
多くの標準的な UNIX のシグナルが提供されています。 ジョブコントロールは、シェルがサポートしていれば動作します。
Cygwin におけるソケット関連の呼び出しは、単に Microsoft によるバークレーソケットの実装である Winsock にある同名の関数を呼び出します。 UNIX でのセマンティクスに合致するよう、 幾つかの修正が必要なだけでした。 最も厄介な違いの一つは、最初のソケット関数が呼び出される前に Winsock が初期化されていなければならないというものです。 結果として、適切な時点でこの初期化を Cygwin が実行する必要があります。 fork 呼び出しを跨ったソケットをサポートするため、 継承したファイル記述子がソケットであった場合、 子プロセスは Winsock を初期化します。
不幸なことに、プロセスの開始時における DLL の暗黙のロードは時間のかかる作業となります。 多くのプロセスはソケットを使用しないので、 Cygwin は Winsock 初期化ルーチンが呼ばれた時点で Winsock DLL を明示的にロードします。 この単純な変更は、GNU configure の時間を 30% スピードアップさせます。
UNIX の select 関数は、 Win32 API の最上位に正しくマップ出来ないもう一つの呼び出しです。 たいへんがっかりさせられたことに、Winsock 中の Win32 の select はソケットハンドルに対してしか動作しません。 我々の実装では、select は異なるタイプのファイルディスクリプタ (ソケット、パイプ、ハンドル、そして独自の Windows メッセージ仮想デバイスである /dev/windows) に対しても通常は機能します。
select 関数に入る時点で最初に行われる処理は、 ファイル記述子を異なるタイプごとに整列することです。 ここで、二つの場合が考えられます。 最も単純なのは、最低一つのファイル記述子が、 可能状態にあることを常に知ることが出来るタイプ (ディスク上のファイルのような)である場合です。 この場合、select は可能状態にあるかどうかを確認するために他のタイプのファイル記述子をポーリングするやいなや、速やかに復帰します。より複雑なのは、 ソケット又はパイプへのファイル記述子が可能状態かどうかを待っている場合です。 これはメインスレッドが自分自身をサスペンドさせ、その後、 ファイル記述子のタイプごとに一つのスレッドを開始することによって実現されています。 個々のスレッドは自分が担当しているタイプのファイルディスクリプタを、 それに対応する Win32 API を呼び出すことによってポーリングします。 スレッドが可能状態になったファイルディスクリプタを発見するやいなや、 そのスレッドはメインスレッドに復帰するよう通知します。 全てのファイル記述子を一度にポーリングした後、select がリターンします。
Cygwin ネットリリースをインストールするには、
http://cygwin.com/ にアクセスして
"Install Cygwin Now!"
をクリックします。これによって、インターネット経由で完全な Cygwin
インストレーションのダウンロードを行う GUI インストーラ(setup.exe と呼ばれています)をダウンロード出来ます。
Cygwin をインストールするには、個々の画面に表示される指示に従って下さい。
setup.exe インストーラは初心者にも使い易くデザインされていますが、
一方で経験豊富なユーザのために柔軟性も残してあります。
ボランティアの開発者チームは絶えず setup.exe
に対する作業を続けています。新しい機能を要求する前に、
CVS README
にある「やるべきことリスト(wishlist)」をチェックして下さい。
CVS 内のバージョンでは、その機能は既に存在していることでしょう!
全てのオプションのデフォルトの値は一般的なインストール用に合うように選ばれていますので、各ページにある Next ボタンを単にクリックしていくだけで、最小の Cygwin 環境が手に入ります。
この唯一の例外は Cygwin のミラーサイトの選択であり、
http://cygwin.com/mirrors.html
にあるリストから試しに選択してみることが出来ます。
setup.exe によるインストールの各ページについての更なる説明が必要なら、
これ以降を続けて読んで下さい。
このガイドは読者が既に UNIX(或いは UNIX 系の OS) に関する基礎的な知識を持っていることを前提としています。読者が UNIX の初心者であれば、
他の情報源
にも当たったほうがよいでしょう。
Cygwin は様々なソフトウェアを管理するためにパッケージを利用しています。
デフォルトである Install from Internet
オプションが選択されると、setup.exe
はパッケージの内容を実際にインストールする前に、パッケージをローカルディレクトリに保存します。
Download from Internet は最初の部分
(パッケージをローカルへと保存する)だけを、そして
Install from Local Directory は次の部分
(パッケージの内容物のインストール)だけを行います。
The Download from Internet オプションは主として基本となる
Cygwin パッケージツリーを特定のコンピュータに作成するためのものです。
ディレクトリ構造をそのままに、完全なローカルのパッケージツリーを別のマシンへとコピーすれば、
Install from Local Directory によって他の様々なマシンへのインストールが可能となります。
例えば、C:\cache\ ディレクトリを作成し、
そこに setup.exe を置いておきます。
setup.exe によって Install from Internet か
Download from Internet を実行してから、C:\cache\
全体を各マシンにコピーし、Install from Local Directory
を選択します。
不幸にして、setup.exe はまだ無人インストールをサポートしていません。
基本的なミラー用の機能は用意されていますが、
Cygwin のインストールを幅広く管理するのであれば、
内容を最新に保つために wget
のようなミラー用のツールを利用することをお勧めします。
Cygwin メーリングリストのある有能なユーザが、この作業を実現するための簡単なデモスクリプトを作成しました。mkcygwget でメーリングリストのアーカイブを探してみて下さい。
Cygwin の Root Directory(デフォルトでは
C:\cygwin)は、Cygwin 環境内での /
となる場所です。このディレクトリの親ディレクトリには書き込み権限がなければならず、
インストールされたファイルにアクセスが可能なような ACL
が設定されていなければなりません。
レジストリの HKEY_LOCAL_MACHINE、或いは
「All Users」スタートメニューに対するアクセス権限がない場合を除き、
Install For オプションの
All Users 或いは Just Me
は、常にデフォルトである All Users にしておいて下さい。
たとえ、貴方がそのマシンで Cygwin を使うと思われる唯一のユーザであったとしてもです。
Just Me を選択した場合、
crond や sshd といったプログラムにおいて問題が発生するでしょう。
必要なパーミッションを持っていないが、それでもこれらのプログラムを利用したいという場合は、Cygwin
メーリングリストのアーカイブを調べて他のユーザの経験を参考にして下さい。
DOS (これは \r\n を利用します)
を選択しなければならない重要な理由がある場合を除いて、
Default Text File Type は
Unix(これは \n を利用します)
のままにしておきます。
Local Package Directory はパッケージをインストールする前に、
setup.exe がキャッシュとしてパッケージを格納しておくディレクトリです。
キャッシュと Cygwin のルートディレクトリとが同じフォルダであってはいけません。
キャッシュの中では、Cygwin のミラーサイトごとに個別のディレクトリが作成されます。
これらのディレクトリは setup.exe
ミラーサイト群や個別のパッケージを扱うために利用されます。
Cygwin のインストールが完了するとキャッシュはもはや不要なものとなりますが、バックアップとして、又は他のシステムへと
Cygwin をインストールするために、或いはパッケージを再インストールする場合に備えて残したままにしておくことも出来ます。
ダウンロード方法の Direct Connection
はパッケージを直接ダウンロードし、IE5
はパフォーマンスを向上させるために Internet Explorer のキャッシュを利用します。
貴方の組織がプロクシサーバか自動構成スクリプトを利用しているのであれば、選択肢
IE5 はそれらの設定も利用します。
もしプロクシサーバが利用出来るのであれば、Use Proxy
セクションでプロクシサーバを手動で設定することも出来ます。不幸なことに現在の setup.exe
では、プロクシサーバのパスワード認証はサポートされていません。
貴方にはどこから Cygwin をダウンロードするかについてを知る方法はないため、最低でも一つのミラーサイトを選択する必要があります。
Cygwin のミラーサイトは地理的にも世界中の様々な場所に分散されています。
http://cygwin.com/mirrors.html
にあるリストを参照し、近い場所を選択して下さい。
Ctrl キーを押しながら一つ一つクリックしていけば、複数のミラーサイトを選択することが出来ます。
ミラーサイトの一覧に上がっていない URL を利用する場合(例えば、貴方の組織が内部的に Cygwin をミラーしている場合など)、その URL を追加することも出来ます。
選択されたミラーサイト毎に、setup.exe
は setup.bz2 という小さなテキストファイルをダウンロードします。
このファイルには各ミラーサイトから取得可能なパッケージのリストに加えて、
setup.exe が解釈して選択ウィンドウに表示するために利用する、
パッケージ単位の基本的な情報が含まれています。このファイルの形式に関する詳細については、
setup.exe のホームページ を参照して下さい。
選択ウィンドウは setup.exe の中でも最も込み入った部分です。
パッケージ群はカテゴリでグループ化されており、更に一つのパッケージは複数のカテゴリ
(ボランティアのパッケージ開発者によって割り当てられています)に所属していることがあります。
個々のパッケージは、階層化された選択ウィンドウ内にあるこれらのカテゴリ内に置かれています。
デフォルトでは setup.exe は Base
カテゴリ内のパッケージ、及びそれらのパッケージが依存しているパッケージのみをインストールするので、結果として最小の
Cygwin インストレーションが出来上がります。しかし、これには gcc(Devel
カテゴリの中にあります)のように、一般的に使われる数多くのツールは含まれていません。
setup.exe は自動的に依存関係にあるパッケージを選択しますので、要求されるパッケージを選択対象から外さないように注意して下さい。
特に、Base カテゴリに含まれているものは全て必要です。
setup.exe の表示方法は変更することが可能です。
インストールしたいパッケージの名前は知っているが、
そのパッケージがどのカテゴリに所属しているか分からない場合などに役立つでしょう。
View ボタンをクリックすると、Category(デフォルト)、
Full(全てのパッケージ)、そして
Partial(アップグレード対象のパッケージのみ)が切り替えられます。
もし UNIX に慣れ親しんでいるのであれば、おそらくはお気に入りのツールを探すために
少なくとも Full の表示を一目見たくなることでしょう。
既に一度でも Cygwin をインストールしたことがあれば、
setup.exe の選択ウィンドウを現在の
Cygwin 環境の管理にも利用することが出来ます。
インストールされたパッケージの情報は Cygwin 環境中の
/etc/setup/ に保持されています。
setup.exe がこのディレクトリを探し出すことが出来なければ、
setup.exe は Cygwin 環境がインストールされていないものとして動作します。
インストールされているパッケージよりも新しいバージョンのパッケージが利用可能である場合、
setup.exe は自動的にパッケージをアップグレード対象とします。
既存のパッケージのアンインストール、再インストール、或いはソースの取得を行うには、
Keep をクリックして Uninstall、Reinstall
或いは Source へとトグルさせます。
また、アップグレード後の再起動を避けるためには、setup.exe
を利用してアップグレードパッケージをインストールする前に、全ての Cygwin
アプリケーションのウィンドウを閉じ、全ての Cygwin プロセスを終了させておきます。
setup.exe 選択ウィンドウの最後の機能は、Previous 及び
Experimental パッケージに対するものです。
デフォルトでは選択ウィンドウには各パッケージの現在のバージョンのみが表示されますが、
ミラーサイトは以前のバージョンを少なくとも一つは保持していますし、時としてテストバージョン或いはベータバージョンのパッケージが利用可能となっていることもあります。
これらのパッケージを参照するには、Prev 又は
Exp ラジオボタンをクリックして下さい。
しかしながら注意して下さい。次回 setup.exe
を実行した際、setup.exe は古いバージョン、或いは実験(experimental)バージョンを現在の安定版で置き換えようとするでしょう。
まず、setup.exe は全ての選択されたパッケージを簡単に選択可能なローカルディレクトリへとダウンロードします。
インストールの前に、setup.exe は各パッケージのチェックサムを調べます。
ローカルディレクトリが(ネットワークドライブのような)遅いメディアである場合、
この作業には長い時間が掛かることでしょう。ダウンロードとインストールの間、
setup.exe は現在の作業とトータルでのディスク残量に関する進捗バーを表示します。
デスクトップ及びスタートメニューに、bash
シェルを起動させるショートカットをインストールするかどうかを選択します。
別のシェルか、ネイティブ Windows 版の rxvt
を利用するほうがよければ、これらのショートカットを自分自身で作成するショートカットのガイドとして利用できるでしょう。
最後に、setup.exe はインストールされたパッケージの設定を正しく完了させるべく、
幾つかの post-install スクリプトを実行します。各スクリプトは個別に実行されるため、
様々なウィンドウがポップアップします。何が行われているのかについて興味があるのであれば、
http://cygwin.com/setup.html
にある Cygwin Package Contributor's Guide を参照して下さい。
最後の post-install スクリプトの処理が完了すると、setup.exe
は完了を告げるダイアログを表示します。
OpenSSH サーバのような幾つかのパッケージでは、手動でのサイト特有の設定が必要となります。
関連するドキュメントは /usr/doc/Cygwin/ 或いは
/usr/share/doc/Cygwin/ ディレクトリの中に格納されているでしょう。
bash を実行する前に、幾つかの環境変数を設定しておく必要があります。 bash が起動する前に非常に重要な環境変数を設定するためのバッチファイルが提供されます。 これは最初に bash を起動するための、最も安全な方法です。 デフォルトでは、このバッチファイルはセットアップ中に指定したルートディレクトリにインストールされ、スタートメニューの「Cygwin」中にも配置されます。 このファイルは、好みに合うように編集出来ます。
CYGWIN 環境変数は
Cygwin 実行環境における共通の設定を行うために使用されます。
bash を実行させる前に
CYGWIN 環境変数に何も設定せずにおくことも出来ますし、DOS シェルで設定するときの方法に似た方法で
tty を設定しておく(^Z を使ったジョブコントロールをサポートする、など)ことも出来ます。
C:\> set CYGWIN=tty notitle glob
PATH 環境変数は Cygwin
アプリケーションが実行ファイルを検索するディレクトリのリストとして扱われます。
この環境変数は Cygwin プロセスが最初に開始された時点で、
Windows フォーマット(C:\WinNT\system32;C:\WinNT
のようなもの)から UNIX フォーマット
(/WinNT/system32:/WinNT)へと変換されます。
bash の外側で Cygwin のツールを利用するつもりであれば、
少なくとも x:\cygwin\bin ディレクトリ
(「x:\cygwin」が
Cygwin インストレーションの「ルート」である場合)が含まれるように設定しておかなければなりません。
HOME 環境変数は、
多くのプログラムがあなたのホームディレクトリの位置を決定するために使用しますので、設定しておくことをお薦めします。
この環境変数もまた、Cygwin プロセスが最初に開始された時点で
Windows フォーマットから変換されます。
bash を実行する前にあなたのホームディレクトリを設定しておいて下さい。
TERM 環境変数は端末タイプを設定します。
この変数に値が設定されていない場合は、
cygwin が自動的に設定されます。
LD_LIBRARY_PATH 環境変数には、
Cygwin の関数 dlopen() がロードする
DLL ファイルを検索するディレクトリのリストを指定します。
この環境変数は Cygwin プロセスが最初に開始されたときに、Windows フォーマットから UNIX フォーマットへと変換されます。
多くの Cygwin アプリケーションは dlopen() を使用しませんので、この変数を指定する必要はありません。
UNIX 的なオブジェクトパーミッションの設定は、
CYGWIN 環境変数 に
(no)ntsec を設定することによって行われます。
デフォルトでは ntsec が設定されています。
ntsec のデザイン上のゴールは、Windows NT のセキュリティ機能を使ってより
UNIX 的なパーミッション構造を実現することにあります。
この変更について説明するため、項2.3.1. 「NT セキュリティ」
では NT セキュリティについての概略を示します。
プロセスの特権 では、プロセスの特権(privileges)に関する ntsec での変更点について議論します。
ファイルパーミッション では UNIX 的なファイルパーミッションの設定について示します。
Cygwin での NT SID
では、/etc/passwd 及び /etc/group
内での SID の利用方法について説明します。
マッピングの漏れ では Windows NT のパーミッションマッピングの漏れを例証します。
ACL API リリース 1.1 で導入された新しいアクセス制御リスト(ACL) API について簡単に記述します。
新しい setuid のコンセプト ではリリース 1.1.3 で導入された setuid のコンセプトに対する新たなサポートについて記述します。
ユーザコンテキストの切り替え では、SYSTEM ユーザを利用したユーザコンテキストの切り替えを行う方法に関する基本について説明します。
特別な値を持つユーザ ID 及びグループ ID
では、/etc/passwd 或いは /etc/group
に存在しないユーザ及びグループを Cygwin が表現する方法について説明します。
NT セキュリティでは、異なる種類の「オブジェクト」に対するアクセスの許可と拒否を規定することが出来ます。 「オブジェクト」とはファイル、プロセス、スレッド、セマフォなどです。
NT セキュリティの主要なデータ構造は「セキュリティ記述子(security descriptor; SD)」構造です。 この構造はオブジェクトが許可(又は拒否)されるパーミッションを明示し、「セキュリティ識別子(security identifiers; SID)」に関連付けられる情報を含んでいます。
SID はユーザ、グループ、ドメインに対するユニークな識別子です。SID は UNIX の UID 及び GID に相当しますが、SID はネットワークを越えてユニークとなるため、より複雑なものとなっています。 以下に例を挙げます。
システム「foo」の SID:
S-1-5-21-165875785-1005667432-441284377
システム「foo」におけるユーザ「johndoe」の SID:
S-1-5-21-165875785-1005667432-441284377-1023
上記の例は SID の表示方法に関する慣習を示しています。 最初の「S」はこれが SID であることを示しています。 次の数値はバージョン番号であり、常に 1 です。 次の番号は「トップレベル権限(top-level authority)」と呼ばれる、 SID の発行元を示す識別子です。
NT ネットワークに所属する個々のシステムは独自の SID を持っていますが、この状況は NT ドメインでは異なり、ドメインコントローラの SID が個々のドメインユーザのベース SID となります。 もしある NT ユーザがドメインユーザとして一つのアカウントを持っており、 それとは別に彼のローカルマシン上のアカウントを持っていた場合、 同じユーザ名とパスワードを使用していたとしても、これらのアカウントはあらゆる状況下で異なるものとなります!
ドメイン「bar」の SID:
S-1-5-21-186985262-1144665072-740312968
ドメイン「bar」におけるユーザ「johndoe」の SID:
S-1-5-21-186985262-1144665072-740312968-1207
SID の最後のパートは「相対識別子(relative identifier; RID)」 と呼ばれ、Cygwin ではデフォルトで UID 及び GID として扱われます。 その名称と上記の例が暗示するように、 この ID は一つのシステム又はドメイン中でのみユニークです。
一人のユーザが 2 つの異なったシステムの間で同じ RID を持つことが可能であるという点に注意して下さい。 それにも関わらず、結果として生成される SID は異なったものとなります。 二つの SID は、NT ネットワーク内での異なるユーザを示しているのです。
UNIX ID と NT SID の間には、「既知グループ(well known groups)」 の存在という非常に大きな違いがあります。 例えば、UNIX には「全てのユーザ」のグループに対する GID はありませんが、 NT ではそれに相当する「Everyone(英語版での名称)」と呼ばれる SID があります。 既知グループの SID は NT ネットワーク内でユニークではありませんが、 それらの意義は間違いようがありません。 既知グループの例としては、以下のようなものがあります。
everyone S-1-1-0 creator/owner S-1-3-0 batch process (「at」コマンドによる) S-1-5-3 authenticated users S-1-5-11 system S-1-5-18
SID の最後の重要なグループは「事前定義グループ(predefined groups)」です。 このグループはドメインの外部にあるシステムにおいて、 主にユーザパーミッションの管理を簡単にするために使われます。 対応する SID はネットワークを越えてユニークではないので、 これらはローカルでのみ解釈されます。
administrators S-1-5-32-544 users S-1-5-32-545 guests S-1-5-32-546 ...
それでは、 パーミッションはどのようにしてオブジェクトに対して与えられるのでしょう? プロセスは SD をオブジェクトに与えます。オブジェクトの SD は 3 つのパートから構成されています。
所有者の SID
グループの SID
これらのパーミッションに付随する、 「アクセス制御リスト(accesses control list: ACL)」と呼ばれる SID のリスト
UNIX は 3 つの異なるパーミッション、即ち、所有者、 グループ、全員に対するパーミッションを作り出すことが出来ます。 それに対して ACL は、潜在的には無限のメンバに対して存在し得ます。 各メンバはアクセス制御エントリ(access control element: ACE)と呼ばれます。 ACE は 3 つの部分から構成されています。
ACE のタイプ
DWORD で記述されるパーミッション
先に述べたパーミッションが設定された SID
ACE の 2 つの重要なタイプは「アクセス許可 ACE」と「アクセス拒否 ACE」です。 Cygwin バージョン 1.1.0 まで、ntsec の機能は「アクセス許可 ACE」しか使用していませんでした。 それ以降のバージョンでは、UNIX パーミッションを可能な限り反映するように「アクセス拒否 ACE」をも使用します。
オブジェクトに対して設定可能なパーミッションは UNIX に比べてより複雑です。 例えば、オブジェクトの削除パーミッションは書き込みパーミッションとは異なったものです。
前述の方法と共に、NT はオブジェクトへのパーミッションを更なる特別な方法で有効にしたり無効にすることが出来ます。 しかし Cygwin ではどうでしょう? POSIX 環境には POSIX システムのセキュリティ仕様がありますが、 NT セキュリティモデルは POSIX のモデルの殆どを再現することができます。 ntsec の手法はこれを Cygwin で実現しようとするものです。
「殆ど? どうして殆どなの???」そう質問されるかもしれませんが、 何故なら NT モデルには漏れがあるからです。詳細については第 5 章で説明します。
系統だったオブジェクトセキュリティの生成は少々分かりにくいものですが、 一般的には 2 つの単純なヴァリエーションだけが使われます。
オペレーティングシステムによって導出されるデフォルトのパーミッション
全員に対する個々のパーミッション
安全なオブジェクトの作成やオープンに利用される関数の引数には、 「セキュリティ属性(security attributes; SA)」 と呼ばれる別のデータ構造体が使われます。この構造体は SD と、 作成またはオープンされるオブジェクトに対して返されるハンドルが子プロセスに継承されるか否かを示すフラグから構成されます。 このプロパティは ntsec では重要ではないので、この文書では SD と SA の違いは無視されます。
Cygwin の制御の元で開始される全てのプロセスには、シグナルを送信する目的で使われるセマフォがアタッチされています。 このセマフォの生成は cigproc.cc の「getsem」関数内で行われています。 この関数に対する最初の引数「CreateSemaphore」は SA です。 ntsec が適用されていない場合、この SA はセマフォに対してデフォルトのセキュリティを割り当てます。 ここで単純な不都合が発生します。 プロセスの所有者だけしかそのプロセスに対してシグナルを送信できないのです。 言い換えれば、そのプロセスの所有者が Administrators グループに属していなければ、Administrator は決してそのプロセスを殺すことが出来ません! プロセスがサービスマネージャから起動されていた場合、これは特に問題となります。
現在の ntsec はプロセス制御セマフォに対し、プロセスのユーザ、Administrators グループ、そしてオペレーティングシステム自身を示す用語「SYSTEM」に対する個々のパーミッションを持った SA を割り当てます。 この SA の生成は「shared.cc」内の「sec_user」関数で行われています。 Administrators グループのメンバはプロセスの所有者に関わらず、Cygwin 上で生成された全プロセスに対してシグナルを送信することができます。
更に、今や「CreateProcess」 によって開始された個々のプロセスは適切なセキュリティ設定を持ちます。 これは「spawn.cc」の「spawn_guts」関数中で定義されています。 他のユーザコンテキストにおいて開始されたプロセスに対するセキュリティ設定も、 新しいユーザの SID を追加する必要があります。 「CreateProcessAsUser」呼び出しによってプロセスが開始された場合、 sec_user 関数は新しいユーザの SID に対する追加のエントリを含んだ SA を生成します。
ntsec が有効であれば、ファイルパーミッションは UNIX と同様に設定されます。 所有者とグループ、そして所有者、グループ、「Everyone」に対する ACE を含んだファイルに対しては SD が割り当てられます。
完全な UNIX 的なパーミッションの設定はファイル security.cc 中で行われます。2 つの関数「get_nt_attribute」と「set_nt_attribute」 がその主要なコードです。SD の読み取りと書き込みは関数「read_sd」と 「write_sd」にて行われます。 「write_sd」はより簡単な関数「SetFileSecurity」の代わりに関数 「BackupRead」を使用します。 なぜなら、「SetFileSecurity」では呼び出し元とは異なる所有者を設定出来ないからです。
Cygwin の外側でファイル「foo」を生成した場合、ls -ln
の結果は次のようになるでしょう。
Administrators グループのメンバとしてログインした場合:
rwxrwxrwx 1 544 513 ... foo
そうでない場合:
rwxrwxrwx 1 1000 513 ... foo
ユーザ ID とグループ ID に注目して下さい。544 は Administrators グループの UID です。これは
Windows NT の「仕様」:-P です。仮にあなたが Administrators
のメンバであったとした場合、あなたが作成した全てのファイルはあなたではなく、Administrators
グループの所有物となります。
第 2 の例は NT のユーザ管理ツールによって作成された最初のユーザの UID を示しています。ユーザとグループには 1000 から始まる連続した番号が振られます。 ユーザとグループは同じ番号体系を使用するので、ユーザとグループの間で同じ ID を共有することは出来ません。
両方の例において、GID 513 には特別な点があります。 この GID はローカルシステムとドメインにおいて異なる名称を持つ既知グループです。 ドメインの外ではこのグループは 「なし」(英語では「None」、ドイツ語では「Kein」、フランス語では「Aucun」などとなります) と呼ばれ、ドメイン内では「Domain Users」と呼ばれます。 不幸にして、グループ「なし」はドメインの外側ではユーザ管理ツール上に表示されません! これは大きな混乱を生じさせますが、マイナスの影響は与えないとは思われます。
ntsec を正しく動かすためには
/etc/passwd と /etc/group
が必要です。Cygwin リリース 1.0 では、
名前と ID は対応する NT の ID と一致していなければなりません!
既に述べたように、Cygwin での ID は NT SID の RID です。
私の NT ワークステーションのユーザ「corinna」の SID は以下の通りです。
S-1-5-21-165875785-1005667432-441284377-1000
最後の番号を覚えておいて下さい。RID は 1000 であり、 これが Cygwin 上での UID となります。
不幸なことに、ドメインに属していないワークステーションとサーバでは、プライマリグループを設定することが出来ません! この場合、ユーザとプライマリグループの間には何らの関連もありません。 NT はプライマリグループとして 513(なし)を返し、既存のローカルグループへのメンバシップについては関与しません。
このようなシステムにおいて、mkpasswd -l -g を使用した際に「なし」をプライマリグループとして使用したくないのであれば(恐らくしたくないですよね)、手作業でプライマリグループを変更する必要があります。
以下の例を見て下さい。これらは私の /etc/passwd 及び
/etc/group の一部分であり、SID を格納する前の状態です(詳細については次の章で説明します)。
私の個人ユーザのエントリ以外、全てのエントリは既知のエントリです。
everyone:*:0:0::: system:*:18:18::: administrator::500:544::/home/root:/bin/bash guest:*:501:546::: administrators:*:544:544::/home/root: corinna::1000:547:Corinna Vinschen:/home/corinna:/bin/tcsh
例 2.1. /etc/passwd
everyone::0: system::18: none::513: administrators::544: users::545: guests::546: powerusers::547:
例 2.2. /etc/group
私が自分のプライマリグループを 513(none)から 547(powerusers)へと変更したことがわかるでしょう。 これによって、Cygwin の内部で私が作成した全てのファイルの所有グループは、none ではなく powerusers となります。これこそが私が望んでいたことです。
passwd ファイル中にはグループも記述されています。これには二つの長所があります。
しばしば、ls -l がより読み取りやすくなります。
NT はグループもファイル所有者として割り当てるからです。
更に、Cygwin の chown によっても、ファイルの所有者としてグループを割り当てることが出来ます。
前述した通り、グループ「SYSTEM」はオペレーティングシステム自身の同義語であり、通常はサービスマネージャによって起動されたプロセスの所有者となります。 サービスマネージャによって起動されたプロセスによって作成されたファイルについても同様です。
Cygwin リリース 1.1 では、
/etc/passwd と /etc/group
の利用についての新しいテクニックが導入されました。
現在、両ファイルはユーザとグループの SID を含んでいます。
SID は /etc/passwd の pw_gecos フィールドの最後に、
そして /etc/group の gr_passwd
フィールドの最後に格納されています。
これには以下の利点があります:
ntsec がドメイン環境でよりよく動作します。
Cygwin における(ユーザ及びグループの)アカウントには、NT 上のアカウント名とは別の名称が利用出来ます。
/etc/passwd 又は /etc/group の名称は、Cygwin
アプリケーション(chown、chmod、ls など)
において透過的に扱われます。
adminstrator::500:513::/home/root:/bin/sh
の代わりに、このように出来ます。
root::500:513::/home/root:/bin/sh
注意: もしそのアカウントを telnet
などで使用するログインアカウントとするつもりであれば、
その名称を変更しないでおくか、或いは Cygwin リリース 1.1 以降にに含まれる
特別なバージョンの login を使用しなければならない点に注意して下さい。
現在、Cygwin の UID と GID は必ずしも NT の SID の RID 部分でなくとも構いません。
root::500:513::/home/root:/bin/sh
の代わりに、このように出来ます。
root::0:513:S-1-5-21-54355234-56236534-345635656-500:/home/root:/bin/sh
UNIX システムとしての UID と GID の採番スキームは、 現在では相互に影響し合うことはありません。そのため、 ユーザとグループで同じ ID を使用することが可能です。
mkpasswd と mkgroup
の両ツールは、必要となるエントリをデフォルトで作成します。
そうしたくなければ、オプション -s 又は --no-sids
を使用することが出来ますが、これはお奨め出来ません。
ntsec は SID を利用することによって、より正しく動作するからです。
/etc/passwd の pw_gecos
フィールドは、コンマ区切りのリストとして定義されていることに注意して下さい。
SID は最後のフィールドでなければなりません!
既に述べた通り、Cygwin でのアカウント名は NT でのアカウント名とは異なるものとすることが出来ます。
もし「telnet」又はそれ以外の方法でログインする場合、特別な login を使用しなければなりません。
そして pw_gecos フィールドには、ドメインを含めた NT
上のユーザ名を定義するために、もう一つのフィールドを追加することが出来ます。
そう、それぞれのドメインのユーザとしてログインすることが出来るのです。
このシンタックスは簡単です。pw_gecos フィールドに
U-ntdomain\ntusername の形式でエントリを追加するだけです。
SID はまだ pw_gecos の最後のフィールドとして残しておかねばならないことを覚えておいて下さい!
the_king::1:1:Elvis Presley,U-STILLHERE\elvis,S-1-5-21-1234-5678-9012-1000:/bin/sh
ローカルユーザに対しては、ドメインを落すだけです。
the_king::1:1:Elvis Presley,U-elvis,S-1-5-21-1234-5678-9012-1000:/bin/sh
どちらの場合でも、ユーザのパスワードは NT のユーザデータベースから取得されます。 passwd ファイルからではありません!
前章と同様、例として私個人の/etc/passwd
と /etc/group を提示します。
これらのファイルはかなり変更されている点に注意して下さい!
変更しなければならない理由はありませんが、
これはテストのためであり、そして…楽しみのためでもあります。
root:*:0:0:Administrators group,S-1-5-32-544:: SYSTEM:*:18:18:,S-1-5-18:/home/system:/bin/bash admin:*:500:513:,S-1-5-21-1844237615-436374069-1060284298-500:/home/Administrator:/bin/bash corinna:*:100:0:Corinna Vinschen,S-1-5-21-1844237615-436374069-1060284298-1003:/home/corinna:/bin/tcsh Guest:*:501:546:,S-1-5-21-1844237615-436374069-1060284298-501:/home/Guest:/bin/bash
例 2.5. /etc/passwd
root:S-1-5-32-544:0: local:S-1-2-0:2: network:S-1-5-2:3: interactive:S-1-5-4:4: authenticatedusers:S-1-5-11:5: SYSTEM:S-1-5-18:18: local_svc:S-1-5-19:19: netwrk_svc:S-1-5-20:20: none:S-1-5-21-1844237615-436374069-1060284298-513:513: bckup_op:S-1-5-32-551:551: guests:S-1-5-32-546:546: pwrusers:S-1-5-32-547:547: replicator:S-1-5-32-552:552: users:S-1-5-32-545:545:
例 2.6. /etc/group
同様の変更を行うのは、このコンセプトを理解している場合にのみにして下さい。 そうでない場合は、何かが正しく動作しなくなっても驚かないで下さい。 破滅を迎えてしまった場合、mkpasswd 及び mkgroup でファイルを作り直すことが出来ます。 特に、ユーザ SYSTEM の UID と名前は変更しないで下さい。 大部分は動作するでしょうが、SYSTEM アカウントの元でローカルサービスとして動作する幾つかの Cygwin アプリケーションは、突如として奇妙な振る舞いを示すかもしれません。
今こそ NT パーミッションにおける漏れについて説明するときです。 公式の文書では、以下のように簡単に説明されています。
アクセス許可 ACE は呼び出し元のグループメンバシップに関して蓄積される。
ACE の順番は重要である。 システムは何らかの必要な権利が拒否されるか、または全ての必要な権利が許可されるまで、順番に ACE を読み続ける。 それ以降に残された ACE は考慮に入れられない。
全てのアクセス拒否 ACE はどのアクセス許可 ACE よりも優先される。
最後のルールは推奨事項であり、決まりではありません。NT は順番とは無関係に ACL を正しく扱います。 希望する順番で ACE を取得するよう、第 2 のルールを修正することは出来ません。
不幸なことに、NT4 のエクスプローラのセキュリティタブでは、 完全にアクセス拒否 ACE を取り扱うことが出来ません。 Windows 2000 のエクスプローラは、ACE を読み込む前にその順番を再整理します。 困ったことに、この整列結果はキャンセルボタンをクリックしても戻りません。
まだ「どこに漏れがあるの?」と尋ねられることでしょう。NT の ACL は POSIX パーミッションの個々の可能な組み合わせを反映することが出来ません。 例えば、
rw-r-xrw-
1 回目の挑戦:
UserAllow: 110 GroupAllow: 101 OthersAllow: 110
ふーむ、許可の蓄積によって、group が実行可能であれば user も実行可能となります。
2 回目の挑戦:
UserDeny: 001 GroupAllow: 101 OthersAllow: 110
今度は user は読み書き可能ですが実行は出来ません。これでいいのでしょうか? いいえ! 不幸にも others が書き込み可能であるため、group も書き込み可能になってしまいます。
3 回目の挑戦:
UserDeny: 001 GroupDeny: 010 GroupAllow: 001 OthersAllow: 110
今度は group は意図した通り書き込み不可になりましたが、しかし不幸なことに、user もまたどこにも書き込み出来ません。どのようにすればこの問題が解決出来るのでしょう? 公式なルールによると、UserAllow は GroupDeny に従わねばなりませんが、しかしこの方法では解決することが出来ないのは明らかです。
唯一の方法:
UserDeny: 001 UserAllow: 010 GroupDeny: 010 GroupAllow: 001 OthersAllow: 110
繰り返します: これは NT4 と Windows 2000 の両方で動作します。GUI だけがこの順番を設定出来ないのです。
ACL を取り扱うため、現在の Cygwin には Solaris
の新しいバージョンで実装されたような ACL API が用意されています。
単純な ACL エントリ(NT の用語では ACE)に対応する新しいデータ構造は、sys/acl.h
中で以下のように定義されています。
typedef struct acl {
int a_type; /* エントリタイプ */
uid_t a_id; /* UID | GID */
mode_t a_perm; /* パーミッション */
} aclent_t;
aclent_t 型の a_perm メンバはファイルモードの読み込み、書き込み、そして実行の各ビットだけを含んでいます。 読み込み権限が許可されたなら、全ての読み込みビット(S_IRUSR、S_IRGRP、S_IROTH)がセットされます。 CLASS_OBJ 又は MASK ACL エントリは、まだ完全には実装されていません。
新しい API 呼び出しを以下に示します。
acl(2), facl(2) aclcheck(3), aclsort(3), acltomode(3), aclfrommode(3), acltopbits(3), aclfrompbits(3), acltotext(3), aclfromtext(3)
Solaris と同様、Cygwin は ACL と共にコマンドラインで動作する
2 つの新しいコマンドを備えています。
getfacl と setfacl です。
前述のコマンドと API 呼び出しに関するオンラインの man ページは、http://docs.sun.com などで見つかります。
ユーザコンテキストを変更する必要がある UNIX アプリケーションは、Windows API には存在しない
setuid 及び seteuid 呼び出しを使用します。
それにも関わらず、これらの呼び出しは Cygwin 1.1.3 以降、Windows NT/2000 の元ではサポートされています。
しかしながら NT セキュリティの性質により、この機能が必要なアプリケーションに対しては修正が必要となります。
NT はユーザとパーミッションを識別するために「アクセストークン」と呼ばれるものを使用します。
ユーザコンテキストを変更するためには、アプリケーションは「アクセストークン」を要求する必要があります。
これは通常、NT の API 関数 LogonUser
を呼び出すことによって実行されます。アクセストークンが返されると、アクセストークンは
ImpersonateLoggedOnUser によってユーザコンテキストを変更するために、
又は CreateProcessAsUser
によって生成された子プロセスのユーザコンテキストを変換するために使用されます。
但し、LogonUser を使用するアプリケーションは、以下の特殊なユーザ権利を持っていなければならないという重大な制限があります。
「オペレーティングシステムの一部として機能(Act as part of the operating system)」 「プロセスレベルトークンの置き換え(Replace process level token)」 「クォータの増加(Increase quotas)」
デフォルトで設定されているユーザ権利では、Administrators にもこの全ての権利が設定されていないということに注意して下さい。
setuid を使用するアプリケーションが最小の変更で移植出来るように、二つの新しい
Cygwin の呼び出しが導入されました。Cygwin に対して正しいアクセストークンを与えれば、POSIX
アプリケーションで利用するのと同様、普通に
seteuid 又は setuid を呼び出すことが出来ます。
sexec 呼び出しは何も必要としません。
setuid を使用するアプリケーションの移植は、以下の簡単な例で示すように行えます。
/* まず、全ての必要な Cygwin 関連ファイルをインクルードする */
#ifdef __CYGWIN__
#include <windows.h>
#include <sys/cygwin.h>
/* Windows のバージョンを決定するために以下の定義を使用する */
#define is_winnt (GetVersion() < 0x80000000)
#endif
[...]
struct passwd *user_pwd_entry = getpwnam (username);
char *cleartext_password = getpass ("Password:");
[...]
#ifdef __CYGWIN__
/* 典型的なパスワードのテストに対するパッチ */
if (is_winnt)
{
HANDLE token;
/* NT のアクセストークンを得ることが出来るかどうか */
token = cygwin_logon_user (user_pwd_entry, cleartext_password);
if (token == INVALID_HANDLE_VALUE)
error_exit;
/* 新しい偽装トークンを Cygwin に通知。
今や Cygwin は、setuid 又は seteuid 呼び出しを使用することに
よってユーザコンテキストを変更出来る。*/
cygwin_set_impersonation_token (token);
}
else
#endif /* CYGWIN */
/* Windows 9x でうまく動作させるための標準的な方法 */
hashed_password = crypt (cleartext_password, salt);
if (!user_pwd_entry ||
strcmp (hashed_password, user_pwd_entry->pw_password))
error_exit;
[...]
/* 後は全て同じです! */
setegid (user_pwd_entry->pw_gid);
seteuid (user_pwd_entry->pw_uid);
execl ("/bin/sh", ...);
アクセストークンを取得するための新しい Cygwin の呼び出しは、以下のように定義されています。
#include <windows.h> #include <sys/cygwin.h> HANDLE cygwin_logon_user (struct passwd *pw, const char *cleartext_password)
異なったユーザでのログオンを行う際には、常にこの関数を呼び出すことが出来ます。 また、更なる呼び出しに備えてアクセストークンを保持しておくためには、第二の関数を使用することが出来ます。
#include <windows.h> #include <sys/cygwin.h> void cygwin_set_impersonation_token (HANDLE hToken);
この呼び出しは、更なる setuid/seteuid
の呼び出しによって変更されるユーザコンテキストを Cygwin に対して通知します。
他のユーザコンテキストへ setuid/seteuid
するための正しいアクセストークンが必要になった場合は、パラメータに自身の UID を指定して
setuid/seteuid
を使用することで、自身のユーザコンテキストへ復帰することが出来ます。
cygwin_logon_user
呼び出しによって返される様々なアクセストークンを覚えていれば、
以下の順序に注意深く従うことにより、ユーザコンテキストを異なるものへと変更することが出来ます。
cygwin_set_impersonation_token (user1_token); seteuid (user1_uid); [...] seteuid (own_uid); cygwin_set_impersonation_token (user2_token); seteuid (user2_uid); [...] seteuid (own_uid); cygwin_set_impersonation_token (user1_token); seteuid (user1_uid); など。
Cygwin リリース 1.3.3 以降、ユーザ権利「プロセスレベルトークンの置き換え」を持つアプリケーションは、通常の setuid、seteuid、setgid
及び setegid
関数を単純に呼び出すだけで、パスワードなしでユーザコンテキストの変更が可能となりました。
一般的に、この権利は SYSTEM ユーザだけに与えられています。
しかしこれによって、例えば rhosts 認証、又は(SYSTEM アカウントを利用して
sshd をサービスとして実行している場合は)公開鍵認証を利用したユーザコンテキストの変更が可能となっています。
この方法における重要な制限は、SYSTEM アカウントで開始されたプロセスは、認証を必要とするネットワーク共有へとアクセス出来ないという点です。 この制限は、パスワードなしでユーザコンテキストを変更したサブプロセスにも及びます。 一般的に、パスワードなしで ssh 又は rsh を利用してログインした際、ユーザはネットワークホームドライブを利用することは出来ません。
現在のユーザのユーザ ID が 400 という特別な値に設定されている場合、そのユーザは
/etc/passwd には含まれませんが、ユーザ名は常に正しく表示されます。
他のユーザ(或いは、ユーザとして扱われる Windows グループ)で
/etc/passwd に含まれないものは、
そのユーザ ID が -1 という特別な値(ls の出力では 65535 となります)となります。
このような場合、そのユーザのユーザ名は「????????」と表示されます。
現在のユーザのログイングループ ID が 401 という特別な値に設定されている場合、そのユーザは
/etc/passwd には含まれません。
他のユーザで /etc/passwd に含まれないものは、
そのユーザのログイングループ ID が -1 という特別な値になっています。
/etc/passwd に含まれているユーザだが、そのユーザのグループが
/etc/group に含まれておらず、かつそのグループはそのユーザのログイングループではないという場合、そのグループのグループ ID は特別な値 -1 に設定されています。
このグループ(ID が -1 のグループ)のグループ名は、「????????」と表示されます。
Cygwin 1.3.20 以前のリリースでは、グループ ID 401
にはグループ名「なし」が与えられていました。Cygwin リリース 1.3.20 以降、グループ ID
401 には、この状況を少しでも解決するために実行するべきであるコマンド名である「mkpasswd」が表示されるようになりました。
また、Cygwin リリース 1.3.20 以降では、もし現在のユーザが
/etc/passwd に含まれているにも関わらず、ユーザのログイングループが
/etc/group に含まれていない場合、グループ名として同様に「mkgroup」を表示します。
要約すれば、次のようになります:
もし現在のユーザが /etc/passwd に含まれていない場合、
グループ名は「mkpasswd」となる。
そうでない場合、現在のログイングループは
/etc/group に含まれておらず、グループ名は「mkgroup」となる。
そうでない場合、/etc/group
に含まれていないグループは「????????」と表示され、
/etc/passwd に含まれていないユーザについても「????????」と表示される。
特別なユーザとグループの名称は表示に利用されるだけであり、
「mkpasswd」という名前を持つユーザが実際に /etc/passwd
に含まれる(或いは、「mkgroup」というユーザが
/etc/group に含まれる)ということを回避させるものではありません。
そのようなことをした場合は、混乱が発生するであろうことには注意して下さい。
デフォルトでは、Cygwin プログラムには 384MB
以上のメモリ(プログラム + データ)を割り当てることは出来ません。
一般的な状況では、この値を変更する必要はないでしょう。
しかし、より多くの実メモリ或いは仮想メモリを必要とする場合は、レジストリの
HKEY_LOCAL_MACHINE (全てのユーザの制限を変更する)又は
HKEY_CURRENT_USER(現在のユーザの制限だけを変更する)セクションに、あるエントリを追加します。
DWORD 値 heap_chunk_in_mb
を追加し、必要となるメモリの上限値を 10 進数表現の MB 単位で設定します。
Cygwin から行うのであれば、Cygwin パッケージに含まれている
regtool プログラムを利用するほうがよいでしょう
(regtool 及び他の Cygwin ユーティリティに関する更なる情報については
項3.7. 「Cygwin ユーティリティ」 を参照するか、各ユーティリティに
--help オプションを付けて実行して下さい)。
システムのレジストリに損傷を与えると、結果としてシステムが使用不能になり得ます。
regtool を利用する場合は常に十分な注意を払って下さい。
この例はメモリの上限を 1024 MB に設定しています。
regtool -i set /HKLM/Software/Cygnus\ Solutions/Cygwin/heap_chunk_in_mb 1024 regtool -v list /HKLM/Software/Cygnus\ Solutions/Cygwin
全ての実行中の Cygwin プロセスを終了させ、再度起動して下さい。 メモリはシステムのスワップスペースのサイズから、実行中のプロセスの全合計サイズを引いた量まで割り当てることが出来ます。 システムスワップは少なくとも物理メモリよりは大きくなければなりません。 スワップ量はコントロールパネルの「システム」を利用して変更することが出来ます。
これは DJ Delorie による簡単なプログラムで、 システムのメモリ割り当ての上限値をテストします。
main()
{
unsigned int bit=0x40000000, sum=0;
char *x;
while (bit > 4096)
{
x = malloc(bit);
if (x)
sum += bit;
bit >>= 1;
}
printf("%08x bytes (%.1fMb)\n", sum, sum/1024.0/1024.0);
return 0;
}
このプログラムは次のようにしてコンパイル出来ます。
gcc max_memory.c -o max_memory.exe
プログラムを実行すると、割り当て可能なメモリの最大量が出力されます。
bash で適切にカット & ペーストが出来るように設定するには、 ウィンドウの「プロパティ」ボタンをクリックし、 「その他」タブを開きます。「範囲指定に使う(簡易編集モード)(原文:Quick Edit)」 をチェックし、「高速に貼り付け」からチェックを外します。 これらの設定は、次回にショートカットから bash を起動したときにも引き継がれます。 同様に、「プログラム」タブ中にある作業ディレクトリも設定出来ます。 「%HOME%」と入力しましょう。
ホームディレクトリには bash の動作をコントロールするための
3 つの初期化ファイルを置いておくべきです。.profile、
.bashrc そして
.inputrc です。
これらの初期化ファイルは、bash の開始前に HOME
が設定されていた場合にのみ読み込まれます。
.profile(他の名称も使用出来ます。bash の man
ページを参照して下さい)は bash コマンドを含んでいます。
これは、bash がログインシェルとして開始された場合、例えば
bash --login として開始されたときに実行されます。
このファイルは環境変数を定義してエクスポートしたり、bash 自身、又は
bash から起動されるプログラムが使用する bash 関数を定義するのに便利です。
必要であれば PATH を再定義するためにも使えます。
現在の作業ディレクトリ(DOS とは違い、デフォルトではローカルディレクトリは検索されません)
もまたコマンド探索対象とするためには、
PATH の最後に「:.」を追加しておくことをお薦めします。
動作が遅くなるのを防ぐために、unset
MAILCHECK を設定するか、既存のメールの inbox を
MAILPATH に指定しておくべきでしょう。
.bashrc は .profile
と似ていますが、bash が対話的に実行される度に実行されるものです。
これは環境を通じて継承されない要素、
例えばエイリアスのようなものを定義するために使われます。
もしログインシェルを使用しないのなら、
先に検討した .profile の内容を、
代わりにこのファイルに記述したいと考えるかもしれません。
shopt -s nocaseglob
は bash にファイル名を大文字小文字の区別を無視する形で認識させることが出来ます。
.bashrc はログインシェルでは自動的に読み込まれないことに注意して下さい。
.profile 中で読み込ませることは出来ます。
.inputrc は、
プログラムがどのように readline ライブラリ
(bash に含まれています)を扱うかをコントロールします。
このファイルは自動的に読み込まれます。
完全な詳細については readline のマニュアル中の
Function and Variable Index を参照して下さい。
以下のような設定について考えてみましょう。
# 補完時に大文字小文字の違いを無視する set completion-ignore-case on # bash を 8 ビットクリーンにする set meta-flag on set convert-meta off set output-meta on
最後のコマンドは、ファイル名補完において大文字小文字の区別を無視させます。
Windows 環境では便利です。次の 3 つのコマンドは bash が
8 ビット文字を表示出来るようにするものであり、アクセント付きの文字を使用する言語では有効でしょう。
less や ls のように
readline を表示に利用しないツールでは、更なる設定が必要です。
.bashrc に以下の内容を記述して下さい。
alias less='/bin/less -r' alias ls='/bin/ls -F --color=tty --show-control-chars'
訳注: 上に記述された .inputrc や
.bashrc におけるは、日本語を利用する際にも有用です。
なお、一部で流布している「.inputrc に set kanji-code sjis
を記述する」という設定方法は、日本語化パッチを適用していない bash では意味を持ちません。
本章では Cygwin 環境と伝統的な UNIX システムの間にある、 幾つかの重要な違いについて記述します。 標準的な UNIX コマンドの知識があることを仮定しています。
Cygwin は Win32(ディレクトリの区切りにバックスラッシュを使う)スタイルのパスと、 POSIX(ディレクトリの区切りにスラッシュを使う)スタイルのパスを共にサポートしています。 UNC パス名(二つのスラッシュと一つのネットワーク名で始まる)もまたサポートしています。
(Linux のような)POSIX オペレーティングシステムには、ドライブ文字という概念はありません。
代わりに、全ての絶対パスは(「c:」のようなドライブ文字の代わりに)スラッシュで始まり、全てのファイルシステムはサブディレクトリとして表現されます
(例えば、新しいディスクを購入してそれを /disk2 というディレクトリにする、といったようになります)。
UNIX システムで動作するように書かれた多くのプログラムでは、単一の統合された POSIX ファイルシステム構造の存在が前提となっているので、Cygwin は それらのプログラムが Windows 上で正常に動作するように、Win32 ファイルシステムに対する特別な内部的 POSIX ビューを提供します。 Cygwin は必要に応じて、Win32 パスと POSIX パスの間の変換用のマッピングを使用します。
mount ユーティリティプログラムは、Win32 ドライブとネットワーク共有を
Cygwin の内部的 POSIX ディレクトリツリーにマップするために使用されます。
これは典型的な UNIX のマウントプログラムのコンセプトと同様です。
Windows での経験が豊富であれば、mount ユーティリティはかつての DOS に存在した
join と非常に似ており、ドライブ文字を任意のサブディレクトリとして扱うことを可能にするといえば分かりやすいかもしれません。
このマッピングは現在のユーザの Cygwin マウントテーブル(Windows レジストリ中に格納されています)に保存され、次回のログインの際にも取り出されることになります。 時として、ユーザ単位でのマウントと同様に、システム全体でのマウント情報を持つことが望ましいので、Cygwin の全利用者が継承するシステム全体のマウントテーブルもまた存在します。 システム全体のテ