UNIX glibc のユーザー情報

C ライブラリは、アプリケーション プロセスとカーネル プロセスとの間のスムーズなやり取りを担うものであり、すべての UNIX システムにおいて最も重要なコンポーネントの 1 つです。

以降では、次の点を確認することができるように、アドバイスおよびバックグラウンド情報を提供します。

  • インストールされている AntiVir スキャナが、コンピュータ環境に対応したものであるかどうか
  • 不整合がある場合の更新プログラムの入手先

バックグラウンド

UNIX システムのほぼすべてのコンポーネント (OS 自体、システム プログラム、大部分のアプリケーション) は、直接 C で記述されているか、または C で記述されたコンポーネントに基づいています。

アプリケーションの動作の基礎となる基本的なルーチンは、通常 libc に含まれています。 これには、ファイルの操作、メモリへの格納、ネットワーク、プロセス管理、オペレーティング システムによって実行されるすべてのサービスへのアクセスなどの機能が含まれています。

これらのルーチンは、無駄を省くためにプログラムごとに再作成されて提供されることはありません。 これらのルーチンは、システム内の中心的な場所にインストールされており、いつでもプログラムから利用できるようになっています。 UNIX では共有ライブラリ (他のプラットフォームにおける DLL のようなライブラリ) の概念がサポートされているため、該当するアプリケーションは、動的リンク バイナリと呼ばれるものに分割されることが一般的です。 プログラム開始時に、リンクされた C ライブラリが、基礎となる基本システムによって最初に提供されます。

この libc の Linux における最も一般的な実装は、glibc (英語) です。 このコードは、一般的かつ広く使用されているすべてのオープン ソース プロジェクトと同様に、継続的に開発および改訂されています。 常にバグが修正され、関数の数が増え、拡張機能が実装されています。 継続的に変更および開発されている一般的な標準に合わせ、この現在進行中のプロセスでも継続的な調整が行われています。

このような理由から、いずれかの箇所で不整合が発生することは事実上避けられません。 表面的には均一で統一されたライブラリに見えても、内部の差異によって異なるアプリケーション要件が要求される可能性もあります。 たとえば、セマンティクスが変更された結果、以前はある方法でデータを解釈していたインターフェイスで、突然解釈方法が他の処理に依存するようになる可能性があります。 他にも、 機能が拡張されたために、パラメータの変更によってインターフェイスの形式が変更されたり、動作方法が変更になることもあります。

このような理由から、ライブラリ (開発の現在の状況および動作) は厳格にバージョン管理されています。 ただし、それでもすべてのバージョンが "完全に" 相互互換であるわけではありません。 通常は、上位互換性および下位互換性が保たれるように設計されます。 しかし実際は、互換性が確保できたとしても、非常に近いバージョンどうしでしか確保できません。 つまり、 互換性を保とうとすると、事実上大きな変更を行うことができません。

では、どうすればよいでしょうか。 オペレーティング システムとアプリケーションのソースが存在している場合、整合性のある状態を達成するためには、システム全体のコンパイルが便利です。 アプリケーションをバイナリとして入手する場合は、ダウンロード時に正しいバージョンを選択する必要があります。 基本コンポーネントを更新する場合は、基本コンポーネントの上位に位置し、更新の影響を受けるコンポーネントに対する依存関係が存在する可能性があることに注意する必要があります。 たとえば、libc のような基本的なシステム コンポーネントを他のバージョンに置換またはアップグレードする場合は、オペレーティング システムだけでなく、すべてのアプリケーション ソフトウェアの更新が必要になることがあります。


AntiVir によるサポートが必要なライブラリ バージョンの特定

互換性および相互運用性の理由から、実行中のアプリケーションが、インストールされている libc バージョンを特定したり、現在の環境で実行可能かどうかを判断したりすることはできません。 そもそもライブラリは、バージョンを特定できるように設計されていません。このような機能を備えた実装が個別になされた場合でも、その手順が他のすべてのシステムやプラットフォームで機能するわけではありません。 同時に、 必要なバージョンと使用可能なバージョンとの間に不整合があるためにアプリケーションを実行できない場合、アプリケーションを起動して独自の動作確認テストを行うことができず、まさにジレンマといえます。

残念ながら、多少面倒ですが、以下に説明する作業をユーザーが行う必要があります。 上記の状況においては、管理者が常にインストールされているソフトウェアの整合性が保たれるように監視する必要があります。管理者以外はこのタスクを行うことができません。 ただし、弊社では、少なくとも問題の理解および解決に役立つガイドラインを提供することはできます。


問題解決

次の問題は、Linux および GNU-C ライブラリに関連しています。 上記の問題は、他のプラットフォームにも当てはまりますが、提供されているバージョンの中から 1 つを選択するというタスクは、現在のところ Linux と GNU libc との組み合わせでのみ存在します。

glibc ライブラリは、"通常のプログラム" として使用可能な形式でハード ディスク上に存在しています。 このことは、開発段階で役立つのみでなく、重要な情報を抽出することも可能になります。

コマンド
/lib/libc.so.6 | head -1
を実行すると、バージョン番号を確認できます (出力には、バージョン番号以外の情報も数多く表示されますが、バージョン番号が出力される最初の行のみを表示しています)。 このコマンドによって "アクセスが拒否されました" のようなエラーが表示された場合や、他の理由によってこのファイルが "プログラム" として認識されない場合は、次のコマンドを使用してプログラムを実行できます。
/lib/ld-linux.so.2 /lib/libc.so.6 | head -1
バージョン番号が 2.0 または 2.1 で始まる場合は、弊社ソフトウェアの glibc20 とマークされたアーカイブを使用する必要があります。 バージョン番号が 2.2 または 2.3 で始まる場合は、glibc22 とマークされたアーカイブを使用する必要があります。 libc ライブラリは、(内部) バージョン 1 のものもありますが、その場合ファイル名は libc.so.5 となります。 この実装は最新ではなく、多くの機能を含むものでもありませんが、このバージョンでは機能に明確な制限があるため (国際化も行われていません)、組み込みシステムに頻繁に導入されています。また、リソースの節約が必要な場合や、更新の必要性がない場合にも使用されます。

libc GNU バージョン以外にも、"軽量" や "非常に高い移植性" などのさまざまな目的を持つ他の libc ライブラリの実装も存在します。 ただし、このソフトウェアは計画的に決定された結果使用されるものであるため ("偶然" 使用されたり、標準のディストリビューションをインストールした結果使用されたりするものではありません)、担当の管理者が、システムについてよく理解していることを前提にしています。 管理者は、これまで議論してきた点について考慮し、最適な実装の glibc を特定できるはずです。 つまり、管理者はどの Avira ソフトウェア アーカイブを使用すべきか、既にわかっているはずです。

libc が実装されたファイルが lib ディレクトリに含まれていない場合に備えて、管理者はこのファイルの場所を知っておく必要があります。 実行するシステム内における共有オブジェクトの場所は、ローダーが把握しています。 わからない場合は、次のコマンドを実行できます。
ldd /bin/ls (または他の動的リンク プログラム)
次に、libc の行を検索します (または、前述のようにプログラムとして起動されるライブラリではない場合は ld-linux を検索します)。


まとめ

外部プログラムは、アプリケーションの高レベルのロジックのみを提供し、低レベルの関数については libc などのシステム コンポーネントを使用します。 これら 2 つのコンポーネントの間に不整合があると、ソフトウェアは正しく動作しません (一見動作するように見える、ときどき動作するがほとんどの場合動作しない、通常はまったく動作せず何も実行されない、ハード ディスクがフォーマットされてしまい大変なことになるなどの、さまざまな現象が発生する可能性があります)。

アプリケーション自体が互換性について十分なテストを行うことはできません。 そのため、システムの整合性や実行可能性を担当するユーザーの協力が不可欠です。 弊社ソフトウェアの Linux バージョンはさまざまな環境に対応した異なるアーカイブで提供されているため、それぞれの環境にインストールされている C ライブラリに基づいて使用するアーカイブを決定する必要があります。

ハード ディスクにインストールされている C ライブラリの完全なファイル パスおよびインストールされている実装のバージョンは、次のコマンドを使用して特定できます。

$ ldd /bin/ls /bin/bash /usr/bin/vi

/bin/ls:

librt.so.1 => /lib/librt.so.1 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40030000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40160000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/bin/bash:

libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40022000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/usr/bin/vi:

libncurses.so.5 => /lib/libncurses.so.5 (0x4001e000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0x40066000)
libdl.so.2 => /lib/libdl.so.2 (0x4006c000)
libperl.so.1 => /usr/lib/libperl.so.1 (0x4006f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4016f000)
libutil.so.1 => /lib/libutil.so.1 (0x4019c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4019f000)
libm.so.6 => /lib/libm.so.6 (0x401f0000)
libc.so.6 => /lib/libc.so.6 (0x40213000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ /lib/libc.so.6 | head -1
GNU C Library stable release version 2.3.1, by Roland McGrath et al.

インストールされている C ライブラリに応じて、Avira ソフトウェアの適切なアーカイブをインストールします。 弊社の Linux 用 AntiVir プログラムは、GNU libc バージョン 2.2 または 2.3 と共に動作するように設計されています。 また、限られたリソースしかないシステムや、他の理由によって libc5 が使用されているシステムに対応するバージョンもあります。 システムで GNU の実装を使用しない管理者は、最適なアーカイブを選択する必要があります。

影響を受ける製品

  • Avira AntiVir MailGate [Linux]
  • Avira AntiVir MailGate [Solaris]
  • Avira MailGate Suite [Linux]
  • Avira WebGate Suite [Linux]
  • Avira WebGate Suite [Solaris]
  • Avira AntiVir Professional, バージョン 10 [Linux]
  • Avira AntiVir Professional, バージョン 10 [Solaris]
  • Avira AntiVir Server, バージョン 10 [Linux]
  • Avira AntiVir Server, バージョン 10 [Solaris]
  • 作成日 : 2007年3月14日水曜日
  • 最終更新日時 : 2011年3月21日月曜日
  • この記事を評価