5.1 レッスン 1

ユーザー識別子（ UID ）とグループ識別子（ GID ）は、それぞれのアカウントを参照するための数値です。初期の実装では16ビット（0から65535）でしたが、21世紀のシステムでは64ビットの UIDと GIDをサポートしています。ユーザーとグループは独立してカウントされるので、UIDと GIDには同じ数値が使われることがあります。

すべてのユーザーは、ひとつの UIDと、 プライマリ GIDを持っています。プライマリGIDは、そのユーザー専用であることも、他のユーザーと共有されていることもあります。それぞれのユーザーは、プライマリグループだけではなく、他のグループのメンバーになることもできます。

現在の多くのLinuxシステムでは、ユーザー名と同じ名前でUIDと同じGIDを割り当てたグループをそれぞれのユーザーに割り当てるのがデフォルトになっています。つまり、newuser というユーザーを作成すると、そのプライマリグループも newuser になります。

Linuxでのスーパーユーザーアカウントは root であり、そのUIDは常に 0です。スーパーユーザーとは、システム管理者 のことであり、他のユーザーを含むシステム全体に対して無制限のアクセスと制御が行えます。

スーパーユーザーのデフォルトのグループも root であり、GIDは 0 です。スーパーユーザーのホームディレクトリは、最上位の専用ディレクトリ /root であり、root 自身しかアクセスすることができません。

root 以外のアカウントは技術的には普通のアカウントですが、Linuxシステムでは ユーザーアカウント という単語で “普通の” （特権がない）アカウントを指すことがあります。少しの例外がありますが、次のような属性（プロパティ）を持っています:

ユーザーアカウントの属性に有効なシェルが定義されていない場合、ユーザーは対話シェルを開くことができません。無効なシェルとして、/sbin/nologin を指定することもあります。例えば、コンソールや SSHアクセス以外のアクセス（例えば セキュアFTP sftp）のみを認証する場合です。

システムアカウント は、システムのインストール時にあらかじめ作られるもので、スーパーユーザー権限では実行されない機能、プログラム、サービスなどが使用します。概念上、これらすべてはオペレーティングシステムの機能です。

システムアカウントはさまざまですが、次のような属性を持っています:

Linuxのほとんどのシステムアカウントはログインすることがないので、属性にシェルを定義する必要はありません。システムアカウントによって所有され実行されるプロセスの多くは、特定のシステムアカウントで実行されるシステムマネージャによって、独自の環境にフォークされます。これらのアカウントはほとんどの場合に、制限されているか、何の特権も持っていません。

通常、システムアカウントは有効なログインシェルを持つべきではありません。有効なログインシェルがあると、セキュリティ上の問題に繋がります。

サービスアカウント は通常、サービスをインストールして設定したときに作成されます。システムアカウントと同様に、これらはスパーユーザー特権を持たずに実行される機能やプログラム、サービス用です。

多くのドキュメントでは、システムアカウントとサービスアカウントを明確に区別していません。ホームディレクトリがあるとしても（サービスアカウントは、システムアカウントに比べると、ホームディレクトリを持っていることが多い） /home の外であること、有効なログインシェルを持たないことなどが似ています。厳密な定義はありませんが、システムアカウントとサービスアカウントの最大の相違点は UIDと GIDです。

いくつかのLinuxディストリビューションには、未だに事前に予約された100未満のUIDがあり、システムのインストール時には作成されませんがシステムアカウントと見なすことができます。例えば、Fedraベース（Red Hatを含む）のLinuxディストリビューションでは、Apache Webサーバーが UID 48（GIDも同じ）を持っていて、明らかにシステムアカウントですが、ホームディレクトリを持っています（通常は /usr/share/httpd か /var/www/html/ ）

ほとんどのアカウントにはログインシェルがありますが、一部のアカウントには対話的なアクセスを必要としないため、セキュリティ上の目的でログインシェルを持たないものもあります。ほとんどのLinuxディストリビューションでは、bash すなわち Bourne Again Shell がデフォルトのログインシェルですが、Cシェル（ csh ）、コーンシェル（ ksh ）、Zシェル（ zsh ）などの他のシェルが利用可能なことがあります。

ユーザーは、chsh コマンドでログインシェルを変更する事ができます。デフォルトでは、コマンドは対話モードで動作し、どのシェルを使用するかを尋ねるプロンプトを表示します。以下のように、シェルの実行ファイルへのフルパスを答えます:

非対話モードでもコマンドを実行することができ、以下のように -s オプションに続けて実行ファイルへのパスを指定します。

ほとんどのアカウントには、ホームディレクトリが定義されています。Linuxでは通常、そのユーザーアカウントが書き込みアクセスを持つのはホームディレクトリのみですが、いくつかの例外（例えば一時ファイルシステム）があります。また、セキュリティ上の理由で、ホームディレクトリに書き込みアクセスを持たないアカウントもあります。

/etc/passwd ファイルは一般に “パスワードファイル” と呼ばれます。各行は、コロン（ : ）で区切られた複数のフィールドを含んでいます。名前とは裏腹に、現在では、このファイルにハッシュ化されたパスワードは含まれていません。

このファイルの構文は次の通りです:

ここでは:

例えば、次の行はユーザー emma に関する情報です:

/etc/group ファイルは、コロン（ : ）で区切ったフィールドに、システムのグループに関する基本的な情報が収められていて、“グループファイル” と呼ばれることもあります。構文は次の通りです:

ここでは:

以下に、students グループに関する情報を含む行を示します:

グループがユーザーのプライマリグループである場合は、メンバーフィールドに記載する必要がありません。ユーザーを記載しても冗長なだけで、記載してもしなくても働きは同じです。

以下の表は “シャドウファイル” とも呼ばれる、/etc/shadow ファイルに収められている属性のリストです。コロン（ : ）で区切られたフィールドが含まれています。たくさんのフィールドがありますが、最初の2フィールドを除くほとんどは、レッスンの範囲外です。

このファイルの行の構文を示します:

ここでは:

以下に /etc/shadow のエントリの例を示します。ここでは、インアクティブ と 失効日 は定義されていません。

POSIXシステムにおける “epoch” （エポック）とは、1970年1月1日（火曜日）の協定世界時（UTC）0時0分0秒です。POSIX日付と時刻のほとんどは、“epoch” からの秒数ですが、/etc/shadow においては “epoch” からの日数です。

さまざまな認証ソリューションが存在しますが、パスワードを保存する基本的な方法は、一方向の ハッシュ関数 を使用することです。システムに平文のパスワードを保管せず、元に戻せないハッシュ値を保管します。パスワードからハッシュ値を求めることはできますが、ハッシュ値をパスワードに戻すことはできません。

パスワードを破るには、パスワードの組み合わせをすべてハッシュしてみる総当たり攻撃が必要です。パスワードのハッシュが破られることを低減するために、Linuxシステムではユーザー毎のパスワードにランダムな “salt” （ソルト）を使用します。そのため、あるLinuxシステムでパスワードをハッシュ化した値と、別のLinuxシステムでハッシュ化した値は、パスワードが同じ場合でも一致しません。

/etc/shadow ファイルにおいて、パスワードにはいくつかの形式があります。一般的なものを以下に示します:

ハッシュ方式、ソルト、ハッシュ文字列の前にはドル記号（ $ ）を置いて区切ります。ソルトの長さは8〜16文字です。一般的な3種の例を示します:

LPI Linux Essentialsの出題範囲と試験の観点からは、ローカルユーザーのハッシュ化されたパスワードが、/etc/shadow ファイルにのみストアされて、認証サービスが読み出せること、スーパーユーザーは別のコマンドで読み出せることを理解していれば十分です。