第 4 章 ユーザーアカウントとグループの管理 (概要)

この章では、ユーザーアカウントとグループを管理するためのガイドラインと管理計画の概要について説明します。また、ユーザーの作業環境のカスタマイズについても説明します。

この章の内容は次のとおりです。

• ユーザーとグループの管理における新機能

• ユーザーアカウントとグループとは

• ユーザーアカウント管理のガイドライン

• グループを管理するガイドライン

• ユーザーアカウントとグループを管理するツール

• ユーザーアカウントとグループ情報の格納場所

• ユーザーの作業環境のカスタマイズ

ユーザーアカウントおよびグループの管理手順については、第 5 章「ユーザーアカウントとグループの管理 (手順)」を参照してください。

ユーザーとグループの管理における新機能

この節では、ユーザーとグループを管理するための Solaris 9 リリースの新機能について説明します。

Solaris 管理コンソールツール群

Solaris 管理コンソールでは、Solaris 管理ツール群を利用でき、このツール群を使用してすべてのユーザーおよびグループ機能を管理できます。Solaris 管理コンソールの詳細については 、第 2 章「Solaris^TM 管理コンソールの操作 (手順)」を参照してください。特定のユーザーおよびグループ管理作業の実行方法については、Solaris ユーザー管理ツールで実行できる作業を参照してください。

Solaris Directory Services

Sun ONE Directory Server および他の LDAP ディレクトリサーバーを使用すると、 LDAP (Lightweight Directory Access Protocol) ディレクトリサービスのユーザーおよびグループ情報を管理できます。ユーザーおよびグループ情報は、NIS、NIS+、またはファイル環境でも管理できます。

LDAP の設定の詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

Sun ONE Directory Server を使ってユーザーおよびグループを管理する方法については、http://docs.sun.com の『iPlanet Directory Server 5.1 管理者ガイド』を参照してください。

プロジェクトでユーザーおよびリソースを管理する

Solaris 9 リリースでは、ユーザーおよびグループを「プロジェクト (project)」(システム使用率またはリソースアロケーションチャージバックの基礎として使用される、作業負荷の構成要素を示す識別子) のメンバーにすることができます。プロジェクトは、Solaris リソース管理機能の一部で、システムリソースの管理に使用されます。

Solaris 9 リリースを実行するシステムにログインするには、ユーザーはプロジェクトのメンバーになる必要があります。デフォルトでは、ユーザーは Solaris 9 リリースのインストール時に group.staff プロジェクトのメンバーになり、他のプロジェクト情報は設定されていません。

ユーザーのプロジェクト情報は、/etc/project ファイルに格納され、このファイルは、ローカルシステム (ファイル)、NIS ネームサービス、または LDAP ディレクトリサービスに保存できます。Solaris 管理コンソールを使用すると、プロジェクト情報を管理できます。

/etc/project ファイルは、ユーザーがログインするために必要ですが、プロジェクトを使用しない場合は管理する必要はありません。

プロジェクトの使用方法および設定方法の詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「プロジェクトとタスク」を参照してください。

ユーザーアカウントとグループとは

基本的なシステム管理作業の 1 つに、サイトの各ユーザーにユーザーアカウントを設定することがあります。通常のユーザーアカウントには、ユーザーがスーパーユーザーのパスワードを知らなくても、システムにログインして、システムを使用するのに必要な情報が含まれています。ユーザーアカウント情報は、次の要素で構成されています。

また、ユーザーアカウントを設定するとき、ユーザーをあらかじめ定義されたユーザーグループに追加できます。グループは一般に、ファイルまたはディレクトリへのグループアクセス権を設定して、グループ内のユーザーだけがファイルとディレクトリにアクセスできるようにするために使用されます。

たとえば、ごく少数のユーザーだけにアクセスさせたい機密ファイルを入れるディレクトリを作成できます。topsecret プロジェクトに携わるユーザーを含む topsecret という名前のグループを設定します。そして、topsecret ファイルの読み取り権を topsecret グループに対して設定します。こうすれば、topsecret グループ内のユーザーだけが、ファイルを読み取ることができます。

また、「役割」という特別な種類のユーザーアカウントは、指定したユーザーに特別な特権を与えるときに使用します。詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。

ユーザーまたはグループは、1 つまたは複数のプロジェクトのメンバーになることができます。プロジェクトは、システムリソースのチャージバックに使用される識別子です。プロジェクトの使用方法については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「プロジェクトとタスク」を参照してください。

ユーザーアカウント管理のガイドライン

次の節では、ユーザーアカウントを作成するガイドラインと計画方法について説明します。

ネームサービス

大規模なサイトでユーザーアカウントを管理する場合、LDAP、NIS、NIS+ などのネームサービスまたはディレクトリサービスを使用できます。ネームサービスまたはディレクトリサービスを使うと、ユーザーアカウント情報を各システムの /etc 内のファイルに格納するのではなく、一元管理できます。ユーザーアカウントにネームサービスまたはディレクトリサービスを使用すれば、サイト全体のユーザーアカウント情報をシステムごとにコピーしなくても、同じユーザーアカウントのままシステム間を移動できます。ネームサービスまたはディレクトリサービスを使用すると、ユーザーアカウント情報を集中化および一元化して管理できます。

ユーザー (ログイン) 名

ユーザーは、ユーザー名 (ログイン名とも呼ばれる) を使って、自分のシステムと、適切なアクセス権を持つリモートシステムにアクセスできます。作成するユーザーアカウントそれぞれに、ユーザー名を選択しなければなりません。

ユーザー名または役割名を作成するときは、次のガイドラインに従ってください。

• 複数のドメインにまたがることもあるユーザーの組織内で、固有であること。

• 2 〜 8 文字の英数字を使用すること。最初の文字は英字でなければならず、少なくとも 1 文字は小文字にする必要があります。

ユーザー名には、ピリオド (.)、アンダースコア (_)、ハイフン (-) を使用できますが、これらの文字により障害が発生するソフトウェアもあるため、使用はお勧めできません。

ユーザー名を探しやすいように、ユーザー名の標準的な割り当て方法を使用することを検討してください。また、ユーザー名はユーザーが覚えやすいものにしてください。単純な規則の例としては、ユーザーのファーストネームの頭文字とラストネームの最初の 7 文字を使用します。たとえば、Ziggy Ignatz は zignatz になります。他のユーザー名と重複する場合は、ユーザーのファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 6 文字を使用します。たとえば、Ziggy Top Ignatz は ztignatz になります。さらに重複する場合、次の方法を検討してください。

• ファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 5 文字を使用する

• 固有の名前になるまで 1、2、3 などの数字を使用する

それぞれの新しいユーザー名は、システムまたは NIS や NIS+ のドメインに登録されているメール別名 (エイリアス) とは異なるものでなければなりません。そうしないと、メールは実際のユーザーにではなく別名に送られることがあります。

ユーザー ID 番号

ユーザー名に関連するものとして、ユーザー識別 (UID) 番号があります。ユーザーがログインしようとするシステムは、UID 番号によってユーザー名を識別したり、ファイルとディレクトリの所有者を識別したりします。多数の異なるシステム上で、ある個人用に複数のユーザーアカウントを作成する場合は、常に同じユーザー名とユーザー ID を使用してください。そうすれば、そのユーザーは、所有権の問題を起こすことなく、システム間で簡単にファイルを移動できます。

UID 番号は、2147483647 以下の整数でなければなりません。UID 番号は、通常のユーザーアカウントと特殊なシステムアカウントの両方に必要です。次の表にユーザーアカウントとシステムアカウントに予約されている UID 番号を示します。

0 から 99 までの UID 番号は予約されていますが、これらの番号でユーザーを追加することはできます。ただし、0 から 99 までの番号を通常のユーザーアカウントには使用しないでください。システム上の定義により、root には常に UID 0、daemon には UID 1、擬似ユーザー bin には UID 2 が設定されます。また、UID が passwd ファイルの先頭にくるように、uucp ログインや、who、tty、ttytype などの擬似的なユーザーログインには低い UID を与えるようにしてください。

ユーザー (ログイン) 名と同様に、固有の UID を割り当てる方法を決めてください。企業によっては、従業員に固有の番号を割り当て、管理者がその従業員番号にある番号を加えて固有の UID 番号を作成している場合もあります。

セキュリティ上のリスクを最小限に抑えるために、削除したアカウントの UID を再利用することは避けてください。どうしても UID を再利用する必要がある場合、はじめから作りなおして、新しいユーザーが前のユーザーの属性に影響されないようにしてください。たとえば、前のユーザーがプリンタの拒否リストに含まれていたためプリンタにアクセスできなかった場合、その属性を新しいユーザーに適用することが正しいとは限りません。

大きな数値のユーザー ID とグループ ID の使用

UID とGID の値の制限が符号付き整数の最大値 (つまり、2147483647) に引き上げられました。

ただし、60000 より大きな数値の UID と GID は機能的に完全でなく、多くの Solaris の機能と互換性がありません。したがって、60000 を超える UID と GID を使用することは避けてください。

次の表では、Solaris の以前のリリースとの相互運用性に関する問題について説明します。

パスワード

ユーザーを追加するときにそのユーザーのパスワードを指定したり、ユーザーが最初にログインするときにパスワードを指定するよう強制したりすることができます。ユーザーのパスワードは、次の構文に準拠している必要があります。

パスワードの最初の 6 文字には、2 文字以上の英字と 
1 文字以上の数字または特殊文字を含める必要があります

ユーザー名は公表されますが、パスワードを知っているのは各ユーザーだけでなければなりません。各ユーザーアカウントには、6 〜8 文字の英数字と特殊文字を組み合わせたパスワードを割り当ててください。

コンピュータシステムのセキュリティを強化するには、ユーザーにパスワードを定期的に変更するよう指示してください。高いレベルのセキュリティを確保するには、ユーザーに 6 週間ごとにパスワードを変更するよう要求してください。低いレベルのセキュリティなら、3 ヵ月に 1 度で十分です。システム管理用のログイン (root や sys など) は、毎月変更するか、root のパスワードを知っている人が退職したり交替したりするたびに変更してください。

コンピュータセキュリティが破られる原因の多くは、正当なユーザーのパスワードが解読される場合です。ユーザーについて何か知っている人が簡単に推測できるような固有名詞、名前、ログイン名、パスワードを使わないよう各ユーザーに対して指示してください。

良いパスワードの例としては以下のようなものが考えられます。

• 英語の単語を組み合わせたフレーズ (たとえば、beammeup)

• フレーズ内の各単語の頭文字だけを集めた、意味のない文字列 。たとえば、SomeWhere Over The RainBow から取った swotrb

• 文字を数字や記号に代えた単語。たとえば、snoopy から文字を代えた sn00py

次のものは、パスワードに不適当です。

• 自分の名前そのもの、逆読み、飛ばし読みのもの

• 家族やペットの名前

• 免許証番号

• 電話番号

• 社会保健番号

• 従業員番号

• 趣味や興味に関連した名前

• 季節に関係のある名前 (たとえば 12 月に Santa を使うなど)

• 辞書にある単語

パスワードの有効期限を設定する

NIS+ または /etc 内のファイルを使用してユーザーアカウント情報を格納する場合は、ユーザーのパスワードにパスワード有効期限を設定できます。Solaris 9 12/02 リリース以降は、LDAP ディレクトリサービスでもパスワードの有効期限がサポートされています。

パスワード有効期限の設定によって、ユーザーに定期的なパスワード変更を強制したり、あるパスワードを保持するのに必要な最低日数以前にパスワードを変更するのを防止したりできます。不正ユーザーが、古くて使用されていないアカウントを使用して、発覚せずにシステムのアクセス権を得るような場合を防止するために、アカウントが無効になる日付を設定することができます。パスワードの有効期限属性を設定するには、passwd コマンドまたは Solaris 管理コンソールのユーザーツールを使用します。

ホームディレクトリ

ホームディレクトリは、ユーザーが独自のファイルを格納するのに割り当てられるファイルシステムの一部分です。ホームディレクトリに割り当てる大きさは、ユーザーが作成するファイルの種類、サイズ、および数によって異なります。

ホームディレクトリは、ユーザーのローカルシステムまたはリモートファイルサーバーのどちらにでも配置できます。どちらの場合も、慣例により、ホームディレクトリは /export/home/username として作成します。大規模なサイトでは、ホームディレクトリをサーバーに格納してください。ホームディレクトリのバックアップおよび復元を簡単にするには、/export/homen ディレクトリごとに別々のファイルシステムを使用してください。たとえば、/export/home1 と /export/home2 を使用します。

ホームディレクトリが配置される場所に関係なく、ユーザーは通常 /home/username という名前のマウントポイントを介してホームディレクトリにアクセスします。Autofs を使用してホームディレクトリがマウントされていると、どのシステムでも /home マウントポイントの下にディレクトリを作成することは許可されません。Autofs が使用されていると、システムはマウントされている /home を特別なものと認識します。ホームディレクトリを自動マウントする方法の詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「autofs 管理作業の概要」を参照してください。

ネットワーク上の任意の位置からホームディレクトリを使用するには、 /export/home/username ではなく、常に $HOME という環境変数の値によって参照するようにしてください。前者はマシンに固有の指定です。さらに、ユーザーのホームディレクトリで作成されるシンボリックリンクはすべて相対パス (たとえば ../../../x/y/x) を使用する必要があります。こうすることによって、そのリンクはどのシステムにホームディレクトリがマウントされても有効になります。

ユーザーの作業環境

ファイルを作成して格納するホームディレクトリのほかに、ユーザーには仕事をするために必要なツールとリソースにアクセスできる環境が必要です。ユーザーがシステムにログインするとき、C、Korn、Bourne シェルなどユーザーの起動シェルで定義される初期設定ファイルによって、ユーザーの作業環境が決定されます。

ユーザーの作業環境を管理するのに便利な方法として、カスタマイズしたユーザー初期設定ファイル (.login、.cshrc、.profile など) をユーザーのホームディレクトリに置くという方法があります。ユーザー初期設定ファイルをユーザー用にカスタマイズする方法については、ユーザーの作業環境のカスタマイズを参照してください。ユーザー初期設定ファイルをカスタマイズした後、新しいユーザーアカウントを作成するときにそれらをユーザーのホームディレクトリに追加できます。

1 回だけ行う作業としてお勧めするのは、「スケルトン」ディレクトリと呼ばれる別々のディレクトリをサーバーに設定することです。 ユーザーのホームディレクトリが格納されるサーバーと同じサーバーを使用できます。スケルトンディレクトリによって、タイプの異なるユーザーに合わせてカスタマイズしたユーザー初期設定ファイルを格納できます。

システム初期設定ファイル (/etc/profile、/etc/.login など) を使用してユーザーの作業環境を管理しないでください。これらのファイルはローカルシステムに存在するため、一元管理されません。たとえば、Autofs を使用してネットワーク上の任意のシステムからユーザーのホームディレクトリをマウントした場合、ユーザーがシステム間を移動しても環境が変わらないよう保証するには、各システムでシステム初期設定ファイルを修正しなければならなくなります。

また、役割によるアクセス制御でユーザーアカウントをカスタマイズする方法もあります。詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。

グループを管理するガイドライン

「グループ」とは、ファイルやその他のシステム資源を共有できるユーザーの集合のことです。たとえば、同じプロジェクトで作業するユーザーはグループを形成することになります。グループは、従来の UNIX グループのことです。

各グループには、名前、グループ識別 (GID) 番号、およびそのグループに属しているユーザー名のリストが必要です。システムは GID によって内部的にグループを識別します。ユーザーは次の 2 つの種類のグループに所属できます。

• 一次グループ – オペレーティングシステムが、ユーザーによって作成されたファイルに割り当てるグループです。各ユーザーは、1 つの一次グループに所属していなければなりません。

• 二次グループ – ユーザーが所属する 1 つまたは複数のグループです。ユーザーは、最大 15 個の二次グループに所属できます。

ユーザーの二次グループは、場合によっては重要でないことがあります。たとえば、ファイルの所有権は、一次グループだけが関係し、二次グループは関係しません。ただし、アプリケーションによってはユーザーの二次グループが関係することがあります。たとえば、ユーザーは、Admintool ソフトウェアを使用するとき sysadmin グループ (グループ 14) のメンバーでなければなりませんが、グループ 14 がそのユーザーの現在の一次グループであるかどうかは問題にはなりません。

groups コマンドを使って、ユーザーが所属しているグループを表示できます。ユーザーは一度に 1 つの一次グループにしか所属できません。ただし、newgrp コマンドを使用して、ユーザーがメンバーとなっている他のグループに一時的に一次グループを変更することはできます。

ユーザーアカウントを追加するとき、ユーザーに一次グループを割り当てるか、デフォルトの staff (グループ10) を使用しなければなりません。一次グループは、すでに存在しているものでなければなりません。存在しない場合は、GID 番号でグループを指定します。ユーザー名は、一次グループに追加されません。ユーザー名が追加されると、リストが長くなりすぎるからです。ユーザーを新しい二次グループに割り当てる前に、そのグループを作成し、それに GID 番号を割り当てなければなりません。

グループは、システムにとってローカルになるか、またはネームサービスを介して管理することができます。グループ管理を単純にするために、NIS のようなネームサービス、または LDAP のようなディレクトリサービスを使用してグループメンバーを集中管理してください。

ユーザーアカウントとグループを管理するツール

次の表に、ユーザーとグループを管理するための推奨ツールを示します。これらのツールはすべて、Solaris 管理コンソールツール群に含まれています。Solaris 管理コンソールの起動および使用方法については、第 2 章「Solaris^TM 管理コンソールの操作 (手順)」を参照してください。

Solaris 管理コンソールを使わずにユーザーアカウントおよびグループを管理する場合に使用する Solaris 管理コマンドについては、表 1–6 を参照してください。これらのコマンドは、認証およびネームサービスサポートを含め、Solaris 管理ツールと同じ機能を提供します。

Solaris ユーザー管理ツールで実行できる作業

Solaris ユーザー管理ツールを使用すると、ローカルシステムまたはネームサービス環境のユーザーアカウントを管理できます。

次の表で、ユーザーツールのユーザーアカウント機能を使って実行可能な作業について説明します。

Solaris 管理コンソールによるホームディレクトリの管理

Solaris 管理コンソールツールを使用してユーザーのホームディレクトリを管理するときは、次のことに注意してください。

• ユーザーツールの「ユーザーを追加 (Add User)」ウィザードを使用してユーザーアカウントを追加し、ユーザーのホームディレクトリを /export/home/username として指定すると、ホームディレクトリが自動マウントされるように自動的に設定されて、次のエントリが passwd ファイルに追加されます。

  /home/username

• ユーザーツールを使用して、ホームディレクトリを自動マウントしないユーザーアカウントを設定するには、この機能を無効にするユーザーアカウントのテンプレートを設定するほかに方法はありません。その後、このテンプレートを使ってユーザーを追加します。「ユーザーを追加 (Add User)」ウィザードでこの機能を無効にすることはできません。

• -x autohome=N オプションを指定して smuser add コマンドを使用すると、ユーザーのホームディレクトリを自動マウントしないでユーザーを追加できます。ただし、smuser delete コマンドには、ユーザーを追加した後でホームディレクトリを削除するオプションはありません。その場合は、ユーザーツールを使用して、ユーザーとユーザーのホームディレクトリを削除する必要があります。

ユーザーアカウントの変更

既存のものと重複するユーザー名や UID 番号を定義しないかぎり、ユーザーアカウントのログイン名や UID 番号を変更する必要はありません。 2 つのユーザーアカウントが、同じユーザー名または UID 番号を持つ場合、次の手順に従ってください。

• 2 つのユーザーアカウントが同じ UID 番号を持つ場合、ユーザーツールを使用して、どちらか一方のアカウントを削除し、もう一度、異なる UID 番号で追加します。ユーザーツールを使用して、既存のユーザーアカウントの UID 番号を変更することはできません。

• 2 つのユーザーアカウントが同じユーザー名を持つ場合、ユーザーツールを使用して、どちらか一方のアカウントを修正し、ユーザー名を変更します。

ユーザーツールを使用してユーザー名を変更する場合でも、ユーザーのホームディレクトリが存在すれば、ホームディレクトリの所有権は変更されます。

ユーザーアカウントの中で変更できる情報に、ユーザーのグループメンバーシップがあります。ユーザーツールの「アクション (Action)」メニューの「プロパティ (Properties)」を選択すると、ユーザーの二次グループを追加したり、削除したりできます。また、グループツールを使ってグループのメンバーリストを直接修正したりすることもできます。

ユーザーアカウントの次の部分も変更できます。

• 説明 (コメント)

• ログインシェル

• パスワードおよびパスワードオプション

• ホームディレクトリおよびホームディレクトリアクセス

• 権限および役割

ユーザーアカウントの削除

ユーザーツールでユーザーアカウントを削除すると、passwd ファイル、group ファイル内のエントリが自動的に削除されます。さらに、ユーザーのホームディレクトリおよびメールディレクトリにあるファイルを削除します。

カスタマイズしたユーザー初期設定ファイルの追加

ユーザーツールを使って、カスタマイズしたユーザー初期設定ファイルを作成することはできませんが、指定された「スケルトン」ディレクトリ内のユーザー初期設定ファイルでユーザーのホームディレクトリを生成することができます。このためには、ユーザーテンプレートツールを使ってユーザーテンプレートを作成し、コピーするユーザー初期設定ファイルを保存するスケルトンディレクトリを指定します。

/etc/skel ディレクトリにあるユーザー初期設定テンプレートをカスタマイズし、ユーザーのホームディレクトリへコピーできます。

パスワードの管理

ユーザーツールを使って、次のようなパスワード管理ができます。

• ユーザーアカウントに通常のパスワードを指定する

• ユーザーが最初のログイン時にパスワードを作成できるようにする

• ユーザーアカウントを無効にするかロックする

• 有効期限とパスワード有効期限情報を指定する

パスワード有効期限は、NIS ネームサービスではサポートされません。

ユーザーアカウントを無効にする

一時的にまたは永続的に、ログインアカウントを無効にしなければならないことがあります。ユーザーアカウントを無効にしたりロックしたりすると、無効なパスワード *LK* がユーザーアカウントに割り当てられ、それ以後ログインできなくなります。

最も簡単にユーザーアカウントを無効にする方法は、ユーザーツールを使用してアカウントのパスワードをロックすることです。

「ユーザープロパティ (User Properties)」画面の「有効期限 (Expiration Date)」フィールドに有効期限を入力して、ユーザーアカウントの有効期間に制限を設けることもできます。

パスワード有効期限を設定するかパスワードを変更することによって、ユーザーアカウントを無効にすることもできます。

ユーザーアカウントとグループ情報の格納場所

ユーザーアカウントとグループ情報は、サイトの方針に応じて、ネームサービスまたはローカルシステムの /etc ファイルのどちらかに格納できます。情報は、NIS+ ネームサービスではテーブルに格納され、NIS ネームサービスではマップに格納され、LDAP ディレクトリサービスではインデックス付きのデータベースファイルに格納されます。

混乱を避けるために、ユーザーアカウントとグループ情報の位置は、「データベース」、「テーブル」、「マップ」という 3 種類の呼び方ではなく、単に「ファイル」と呼びます。

ほとんどのユーザーアカウント情報は、passwd ファイルに格納されます。ただし、パスワード暗号とパスワード有効期限は、NIS か NIS+ を使用するときは passwd ファイルに、/etc ファイルを使用するときは /etc/shadow ファイルに格納されます。NIS を使用するとき、パスワード有効期限は使用できません。

グループ情報は group ファイルに格納されます。

passwd ファイルのフィールド

passwd ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。

username:password:uid:gid:comment:home-directory:login-shell

たとえば、次のようになります。

kryten:x:101:100:Kryten Series 4000 Mechanoid:/export/home/kryten:/bin/csh

次の表では、passwd ファイルの各フィールドについて説明します。

デフォルトの passwd ファイル

Solaris のデフォルトの passwd ファイルには、標準のデーモン用のエントリが入っています。デーモンとは、通常ブート時に起動され、システム全体で有効な操作 (印刷、ネットワークの管理、ポートの監視など) を実行するプロセスです。

root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:

shadow ファイルのフィールド

shadow ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。

username:password:lastchg:min:max:warn:inactive:expire

たとえば、次のようになります。

rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978

次の表では、shadow ファイルの各フィールドについて説明します。

group ファイルのフィールド

group ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。

group-name:group-password:gid:user-list

たとえば、次のようになります。

bin::2:root,bin,daemon

次の表では、group ファイルの各フィールドについて説明します。

デフォルトの group ファイル

Solaris のデフォルトの group ファイルには、システム全体に有効な操作 (印刷、ネットワーク管理、電子メールなど) をサポートする次のようなシステムグループが記述されています。これらのグループの多くは、passwd ファイルのエントリに対応しています。

root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
smmsp::25:smmsp
sysadmin::14:root
nobody::60001:
noaccess::60002:
nogroup::65534:

ユーザーの作業環境のカスタマイズ

ユーザーのホームディレクトリの設定には、ユーザーのログインシェルにユーザー初期設定ファイルを提供することも含まれます。ユーザー初期設定ファイルは、ユーザーがシステムにログインしたあとにユーザーのために作業環境を設定するシェルスクリプトです。基本的にシェルスクリプトで行える処理はどれもユーザー初期設定ファイルで実行できます。主に、ユーザーの検索パス、環境変数、ウィンドウ機能の環境など、ユーザーの作業環境を定義します。次の表に示すように、各ログインシェルには、1 つまたは複数の、固有のユーザー初期設定ファイルがあります。

Solaris 環境には、次の表に示すように、各システムの /etc/skel ディレクトリに、各シェル用のデフォルトのユーザー初期設定ファイルが提供されています。

これらのファイルを変更して、すべてのユーザーに共通な作業環境を提供する標準のファイルセットを作成できます。または、異なるタイプのユーザーに作業環境を提供することもできます。異なるタイプのユーザーにユーザー初期設定ファイルを作成する手順については、ユーザー初期設定ファイルをカスタマイズする方法を参照してください。

ユーザーツールで新しいユーザーアカウントを作成して、ホームディレクトリを作成するオプションを選択すると、選択したログインシェルに合わせて次のファイルが作成されます。

useradd コマンドで新しいユーザーアカウント追加するために、-k オプションと -m オプションで /etc/skel ディレクトリを指定した場合、3 つの /etc/skel/local* ファイルと /etc/skel/.profile ファイルがすべてユーザーのホームディレクトリにコピーされます。この時点で、これらのファイルの名前をユーザーのログインシェルに合わせて変更する必要があります。

サイト初期設定ファイルの使用方法

ユーザー初期設定ファイルは管理者とユーザーの両方によってカスタマイズできます。この重要な機能は、サイト初期設定ファイルと呼ばれる、グローバルに配布されるユーザー初期設定ファイルによって実現します。サイト初期設定ファイルを使用して、ユーザーの作業環境に新しい機能を絶えず導入でき、しかもユーザーはユーザー初期設定ファイルをカスタマイズすることもできます。

ユーザー初期設定ファイルでサイト初期設定ファイルを参照するとき、サイト初期設定ファイルに対して行なったすべての更新は、ユーザーがシステムにログインするときかユーザーが新しいシェルを起動するとき自動的に反映されます。サイト初期設定ファイルは、ユーザーを追加したときにはなかったサイト全体の変更をユーザーの作業環境に配布するよう設計されています。

ユーザー初期設定ファイルでできるカスタマイズは、サイト初期設定ファイルでも行えます。これらのファイルは通常はサーバー、またはサーバーのグループにあり、ユーザー初期設定ファイルの最初の行に現れます。また、各サイト初期設定ファイルは、それを参照するユーザー初期設定ファイルと同じ型のシェルスクリプトでなければなりません。

C シェルのユーザー初期設定ファイルでサイト初期設定ファイルを参照するには、ユーザー初期設定ファイルの最初に次のような行を挿入してください。

source /net/machine-name/export/site-files/site-init-file

Bourne または Korn シェルのユーザー初期設定ファイルでサイト初期設定ファイルを参照するには、ユーザー初期設定ファイルの最初に次のような行を入れてください。

. /net/machine-name/export/site-files/site-init-file

ローカルシステムへの参照を避ける

ユーザー初期設定ファイルに、ローカルシステムへの固有の参照は追加しないでください。初期設定ファイルの設定は、ユーザーがどのシステムにログインしても有効になる必要があります。たとえば、次のようになります。

• ユーザーのホームディレクトリをネットワーク上の任意の位置で利用できるようにするには、常に環境変数の値 $HOME を使用してホームディレクトリを参照してください。たとえば、/export/home/username/bin ではなく $HOME/bin を使用してください。$HOME は、ユーザーが別のシステムにログインする場合でも有効で、その場合ホームディレクトリは自動マウントされます。

• ローカルディスクのファイルにアクセスするには、/net/system-name/directory-name などのグローバルパス名を使用してください。システムが Autofs を実行していれば、/net/system-name で参照されるディレクトリはすべてユーザーがログインする任意のシステムに自動的にマウントできます。

シェル機能

次の表に各シェルの基本的な機能を示します。ユーザー初期設定ファイルを作成するのにどのシェルがどんな機能を提供するか参考にしてください。

シェル環境

シェルは、login プログラム、システム初期設定ファイル、ユーザー初期設定ファイルによって定義される変数を含む環境を管理します。また、一部の変数はデフォルトで定義されます。シェルには次の 2 種類の変数があります。

• 環境変数 – シェルによって生成されるすべてのプロセスにエクスポートされる変数。環境変数の設定値は env コマンドで表示できます。PATH などを含む環境変数の一部が、シェルそのものの動作に影響を与えます。

• シェル (ローカル) 変数 – 現在使用中のシェルだけに関係する変数。C シェルの場合は、シェル変数は環境変数と特別に対応しています。これらのシェル変数は user、term、home、path です。シェル変数は、対応する環境変数の値によって初期設定されます。

C シェルでは、小文字を使って set コマンドでシェル変数を設定し、大文字を使って setenv コマンドで環境変数を設定します。シェル変数を設定すると、対応する環境変数が設定され、その逆もあります。たとえば、path シェル変数を新しいパスで更新すると、シェルは PATH 環境変数も新しいパスで更新します。

Bourne、Korn の両シェルでは、何らかの値に等しい大文字の変数名を使ってシェル変数と環境変数を設定できます。また、export コマンドを使って、その後に実行されるコマンドの変数をアクティブにする必要があります。

すべてのシェルで、シェル変数と環境変数は一般的に大文字の名前で参照します。

ユーザー初期設定ファイルで、ユーザーのシェル環境を、あらかじめ定義された変数の値を変更するか、変数を追加することによってカスタマイズできます。次の表に、ユーザー初期設定ファイルで環境変数を設定する方法を示します。

次の表では、ユーザー初期設定ファイルでカスタマイズできる環境変数とシェル変数について説明します。各シェルで使用される変数の詳細については、 sh(1)、 ksh(1)、 csh(1) の各マニュアルページを参照してください。

PATH 変数

ユーザーが絶対パス名でコマンドを入力すると、シェルはそのパス名を使ってコマンドを探します。ユーザーがコマンド名しか指定しないと、シェルは PATH 変数で指定されているディレクトリの順でコマンドを探します。コマンドがいずれかのディレクトリで見つかれば、シェルはコマンドを実行します。

デフォルトのパスがシステムで設定されますが、大部分のユーザーはそれを変更して他のコマンドディレクトリを追加します。環境の設定や、正しいバージョンのコマンドまたはツールへのアクセスに関連して発生するユーザーの問題の多くは、パス定義の誤りが原因です。

パスの設定のガイドライン

次に、効率的な PATH 変数を設定するためのガイドラインをいくつか示します。

• セキュリティが特に問題とならないときは、現在の作業ディレクトリ (.) をパスの最初に指定します。しかし、現在の作業ディレクトリをパスに入れると、セキュリティ上の問題となることがあり、特にスーパーユーザーにとって問題となります。

• 検索パスはできるだけ短くしておきます。シェルはパスで各ディレクトリを探します。コマンドが見つからないと、検索に時間がかかり、システムのパフォーマンスが低下します。

• 検索パスは左から右に読まれるため、通常使用するコマンドをパスの初めの方に指定するようにしてください。

• パスでディレクトリが重複していないか確認してください。

• 可能であれば、大きなディレクトリの検索は避けてください。大きなディレクトリはパスの終わりに指定します。

• NFS^TM サーバーが応答しないときに「ハング」の可能性を少なくしたり、不要なネットワークトラフィックを削減するよう、NFS がマウントするディレクトリより前にローカルディレクトリを指定します。

例 — ユーザーのデフォルトパスの設定

次の例は、ユーザーのデフォルトパスがホームディレクトリと他の NFS マウントディレクトリを含むように設定する方法を示します。現在の作業ディレクトリはパスの最初に指定されます。C シェルユーザー初期設定ファイルでは、次の行を追加してください。

set path=(. /usr/bin $HOME/bin /net/glrr/files1/bin)

Bourne または Korn シェルユーザー初期設定ファイルでは、次の行を追加してください。

PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin
export PATH

ロケール変数

LANG および LC 環境変数は、時間帯と照合順序、および日付、時間、通貨、番号の書式など、ロケール固有の変換と表記をシェルに指定します。さらに、ユーザー初期設定ファイルで stty コマンドを使って、システムが複数バイト文字をサポートするかどうかを設定できます。

LANG は、ロケールのすべての変換と表記を設定します。特に必要な場合、これとは別に LC_COLLATE、LC_CTYPE、 LC_MESSAGES、LC_NUMERIC、 LC_MONETARY、LC_TIME の各 LC 変数によってその他の設定を行えます。

次の表は、LANG と LC 環境変数の値の一部を示します。

例 — LANG 変数によるロケールの設定

次の例は、LANG 環境変数を使ってロケールを設定する方法を示しています。C シェルユーザー初期設定ファイルでは、次の行を追加してください。

setenv LANG de

Bourne または Korn シェルユーザー初期設定ファイルでは、次の行を追加してください。

LANG=DE; export LANG

デフォルトのファイルアクセス権 (umask)

ファイルまたはディレクトリを作成したときに設定されるデフォルトのファイルアクセス権は、ユーザーマスクによって制御されます。ユーザーマスクは、初期設定ファイルで umask コマンドによって設定されます。現在のユーザーマスクの値は、umask と入力して Return キーを押すと表示できます。

ユーザーマスクは、次の 8 進値で構成されます。

• 最初の桁でそのユーザーのアクセス権を設定する

• 2 桁目でグループのアクセス権を設定する

• 3 桁目で「その他」(ワールドとも呼ばれる) のアクセス権を設定する

最初の桁がゼロの場合、その桁は表示されません。たとえば、umask を 022 に設定すると、22 が表示されます。

設定する umask の値は、与えたいアクセス権の値を 666 (ファイルの場合) または 777 (ディレクトリの場合) から引きます。引いた残りが umask に使用する値です。たとえば、ファイルのデフォルトモードを 644 (rw-r--r--) に変更したいとします。このとき 666 と 644 の差 022 が umask コマンドの引数として使用する値です。

また、次の表から umask 値を決めることもできます。この表は、umask の各 8 進値から作成される、ファイルとディレクトリのアクセス権を示します。

次の例は、デフォルトのファイルアクセス権を rw-rw-rw- に設定します。

umask 000

ユーザー初期設定ファイルとサイト初期設定ファイルの例

ここでは、ユーザー自身の初期設定ファイルをカスタマイズする場合に使用する、ユーザー初期設定ファイルとサイト初期設定ファイルの例を示します。例の中のシステム名やパス名は、実際のサイトに合わせて置き換えてください。

例 — .profile ファイル

1 PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:. 
2 MAIL=/var/mail/$LOGNAME 
3 NNTPSERVER=server1 
4 MANPATH=/usr/share/man:/usr/local/man 
5 PRINTER=printer1 
6 umask 022 
7 export PATH MAIL NNTPSERVER MANPATH PRINTER 

1. ユーザーのシェル検索パスを設定する

2. ユーザーのメールファイルへの検索パスを設定する

3. ユーザーの Usenet ニュースサーバーを設定する

4. マニュアルページへのユーザーの検索パスを設定する

5. ユーザーのデフォルトプリンタを設定する

6. ユーザーのデフォルトのファイル作成アクセス権を設定する

7. 指定された環境変数をエクスポートする

例 — .cshrc ファイル

1 set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin)
2 setenv MAIL /var/mail/$LOGNAME 
3 setenv NNTPSERVER server1 
4 setenv PRINTER printer1 
5 alias h history 
6 umask 022 
7 source /net/server2/site-init-files/site.login 

1. ユーザーのシェル検索パスを設定する

2. ユーザーのメールファイルへの検索パスを設定する

3. ユーザーの Usenet ニュースサーバーを設定する

4. ユーザーのデフォルトプリンタを設定する

5. history コマンドの別名 (エイリアス) を作成する。これにより、h と入力するだけで history コマンドを実行できる

6. ユーザーのデフォルトのファイル作成アクセス権を設定する

7. 指定されたサイト初期設定ファイルを読み込む

例 — サイト初期設定ファイル

次のサイト初期設定ファイルの例では、ユーザーは特定のバージョンのアプリケーションを選択できます。

# @(#)site.login
main: 
echo "Application Environment Selection"
echo ""
echo "1. Application, Version 1"
echo "2. Application, Version 2"
echo "" 
echo -n "Type 1 or 2 and press Return to set your 
application environment: " 
 
set choice = $<	
 
if ( $choice !~ [1-2] ) then 
goto main 
endif 
 
switch ($choice) 
case "1": 
setenv APPHOME /opt/app-v.1 
breaksw 
 
case "2": 
setenv APPHOME /opt/app-v.2 
endsw

次のようにして、このサイト初期設定ファイルをユーザーの .cshrc ファイル (C シェルユーザーのみ使用可能) で参照させることができます。

source /net/server2/site-init-files/site.login

この行では、サイト初期設定ファイルは site.login という名前で、server2 という名前のサーバー上にあります。また、自動マウンタがユーザーのシステムで実行されていることを前提としています。