この章では、ユーザーアカウントとグループを管理するためのガイドラインと計画、ネットワーク環境でユーザーアカウントとグループを設定する方法について概要を説明します。また、ユーザーアカウントとグループ情報を格納するファイル、およびユーザーの作業環境のカスタマイズについて説明します。
この章の内容は次のとおりです。
ユーザーアカウントとグループを管理する手順については、第 3 章「ユーザーアカウントとグループの設定と管理 (手順)」を参照してください。
この Solaris リリースでは、ユーザーやグループの役割 (role) によってアクセス制御を設定する RBAC (Role-based Access Control) によって、スーパーユーザーの特権の一部をまとめてユーザーアカウントに割り当てることができます。この機能によって、特定の問題だけを解決しなければならないユーザーに、スーパーユーザーのすべての特権を与える必要がなくなります。
詳細は、『Solaris のシステム管理 (第 2 巻)』の「役割によるアクセス制御」を参照してください。
基本的なシステム管理作業の 1 つに、サイトにおいて各ユーザーにユーザーアカウントを設定することがあります。通常のユーザーアカウントには、ユーザーがシステムにログインして、システムを (スーパーユーザーのパスワードを知らなくても) 使用するのに必要な情報が含まれます。ユーザーアカウント情報は、主に次の 4 つで構成されています。
構成要素 |
説明 |
---|---|
ユーザー名 | |
パスワード | |
ユーザーのホームディレクトリ |
通常、ログイン時にユーザーのディレクトリになるディレクトリ。通常ホームディレクトリには、そのユーザーの大部分のファイルが含まれます。 |
ユーザー初期設定ファイル |
また、ユーザーアカウントを設定するとき、ユーザーをあらかじめ定義されたユーザーグループに追加できます。グループは一般に、 (ファイルまたはディレクトリへのグループアクセス権を使用して) グループ内のユーザーだけがファイルとディレクトリにアクセスできるようにするために使用されます。
たとえば、ごく少数のユーザーだけにアクセスさせたい最高機密のファイルを入れるディレクトリを作成できます。極秘プロジェクトに携わるユーザーを含む topsecret という名前のグループを設定し、最高機密ファイルの読み取り権を topsecret グループに対して設定します。こうすれば、topsecret グループ内のユーザーだけが、ファイルを読み取ることができます。
また、システム管理の役割に対応した、特別な種類のユーザーアカウントもあります。このユーザーアカウントは、指定したユーザーに特別な特権を与えるときに使用します。詳細は、『Solaris のシステム管理 (第 2 巻)』の「役割によるアクセス制御」を参照してください。
次の節では、ユーザーアカウントを作成するガイドラインと計画方法について説明します。
大規模なサイトでユーザーアカウントを管理する場合、NIS または NIS+ などのネームサービスを使用できます。ネームサービスにより、ユーザーアカウント情報を各システムの /etc 内のファイルに格納するのではなく、1 ヶ所で一貫した管理を行えます。ユーザーアカウントにネームサービスを使用すれば、サイト全体のユーザーアカウント情報をシステムごとに /etc 内のファイルにコピーしなくても、同じユーザーアカウントのままシステム間を移動できます。
ユーザーは、ユーザー名 (ログイン名とも呼ばれる) を使って、自分のシステムと、適切なアクセス権を持つリモートシステムにアクセスできます。作成するユーザーアカウントそれぞれに、ユーザー名を選択しなければなりません。ユーザー名は、次の条件を満たしていなければなりません。
複数のドメインにまたがることもあるユーザーの組織内で、固有であること。
ユーザー名の標準的な作り方を決めておくと便利です。ユーザー名はユーザーが覚えやすいものにしてください。単純な規則の例としては、ユーザーのファーストネームの頭文字とラストネームの最初の 7 文字を使用します。たとえば、Ziggy Ignatz は zignatz になります。他のユーザー名と重複する場合は、ユーザーのファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 6 文字を使用します。たとえば、Ziggy Top Ignatz は ztignatz になります。さらに重複する場合、固有の名前になるまで、ファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 5 文字、および 1、2、3 などの数字を使用できます。
それぞれの新しいユーザー名は、システムまたは NIS や NIS+ のドメインに登録されているメール別名 (エイリアス) とは異なるものでなければなりません。そうしないと、メールは実際のユーザーにではなく別名に送られることがあります。
ユーザー名に関連するものとして、ユーザー ID (UID) 番号があります。ユーザーがログインしようとするシステムは、UID 番号によってユーザー名を識別したり、ファイルとディレクトリの所有者を識別します。多数の異なるシステム上で、ある個人用に複数のユーザーアカウントを作成する場合は、常に同じユーザー名とユーザー ID を使用してください。そうすれば、そのユーザーは、所有権の問題を起こすことなく、システム間で簡単にファイルを移動できます。
UID 番号は、2147483647 以下の整数でなければなりません。また、通常のユーザーアカウントと特殊なシステムアカウントに必要です。表 2-1 にユーザーアカウントとシステムアカウントに予約されている UID 番号を示します。
表 2-1 予約済みの UID 番号
ユーザー ID 番号 |
ログインアカウント |
説明 |
---|---|---|
0 - 99 |
root、daemon、bin、sys、など |
システムアカウント |
100 - 2147483647 |
通常のユーザー |
汎用アカウント |
60001 |
nobody |
アクセス権のないユーザー |
60002 |
noaccess |
Solaris 2.0 およびその互換バージョンと SVR4 リリースとの互換性のために提供 |
0 から 99 までの UID 番号は予約されていますが、これらの番号でユーザーを追加することはできます。ただし、通常のユーザーアカウントには使用しないでください。システム上の定義により、root には常に UID 0、daemon には UID 1、擬似ユーザー bin には UID 2 が設定されます。また、UID が passwd ファイルの先頭にくるように、uucp ログインや、who、tty、ttytype などの擬似的なユーザーログインには低い UID を与えるようにしてください。
ユーザー (ログイン) 名と同様に、固有の UID を割り当てる方法を決めてください。企業によっては、固有の従業員番号に、管理者が 1000 を加えて固有の UID 番号を作成している場合もあります。
セキュリティ上のリスクを最小限に抑えるために、削除したアカウントの UID を再利用することは避けてください。どうしても UID を再利用する必要がある場合、はじめから作りなおして、新しいユーザーが前のユーザーの属性に影響されないようにしてください。たとえば、前のユーザーがプリンタの拒否リストに含まれていたためプリンタにアクセスできなかった場合、その属性を新しいユーザーにも適用するとは限りません。必要な場合には、固有の UID が使い果たされたとき、1 つの NIS+ ドメイン内で重複する UID を使用することができます。
以前の Solaris ソフトウェアリリースでは、32 ビットのデータ型を使用してユーザー ID (UID) とグループ (GID) を格納していましたが、UID と GID に使用できる最大値は 60000 に制限されていました。Solaris 2.5.1 リリースおよびその互換バージョンからは、UID と GID の値の制限が符号付き整数の最大値 (つまり、2147483647) に引き上げられました。
60000 を超える UID と GID は機能的に完全でなく、多くの Solaris の機能と互換性がありません。したがって、60000 を超える UID と GID を使用することは避けてください。
Solaris の以前のリリースとの相互運用性については、表 2-2 を参照してください。
表 2-2 60000 を超える UID と GID の相互運用性に関する問題
分類 |
製品またはコマンド |
問題または注意 |
---|---|---|
NFSTM 互換性 |
SunOSTM 4.0 NFS ソフトウェアおよびその互換バージョン |
NFS サーバーとクライアントのコードは、大きな UID と GID を 16 ビットに切り捨てる。これによって、大きな UID と GID を使用している環境において SunOS 4.0 およびその互換バージョンのシステムを使用すると、セキュリティの問題が発生する可能性がある。SunOS 4.0 およびその互換バージョンのシステムにはパッチが必要である。 |
ネームサービスの相互運用性 |
NIS ネームサービスおよびファイルベースのネームサービス |
60000 を超える UID を持つユーザーは、Solaris 2.5 およびその互換バージョンが動作しているシステムでは、ログインしたり、su コマンドを使用できるが、そのユーザーの UID と GID は 60001 (nobody) に設定される。 |
|
NIS+ ネームサービス |
60000 を超える UID を持つユーザーは、Solaris 2.5 およびその互換バージョンと NIS+ ネームサービスが動作しているシステムではアクセスが拒否される。 |
UID と GID の表示 |
OpenWindows のファイルマネージャ |
OpenWindowsTM のファイルマネージャを拡張ファイルリスト表示オプションで使用する場合、大きな UID と GID は正しく表示されない。 |
表 2-3 大きな UID と GID の制限の要約
ユーザー名は公表されますが、パスワードを知っているのは各ユーザーだけでなければなりません。各ユーザーアカウントには、6 文字から 8 文字の英数字と特殊文字を組み合わせたパスワードを割り当ててください。ユーザーアカウントを作成するときにユーザーのパスワードを設定します。ユーザーは、システムに初めてログインするときにそのパスワードを変更できます。
コンピュータシステムのセキュリティを強化するには、ユーザーにパスワードを定期的に変更するよう指示してください。高いレベルのセキュリティを確保するには、ユーザーに 6 週間ごとにパスワードを変更するよう要求してください。低いレベルのセキュリティなら、3 ヵ月に 1 度で十分です。システム管理用のログイン (root や sys など) は、毎月変更するか、root のパスワードを知っている人が退職したり交替したりするたびに変更してください。
コンピュータセキュリティが破られる原因の多くは、正当なユーザーのパスワードが解読される場合です。ユーザーについて何か知っている人が簡単に推測できるような固有名詞、名前、ログイン名、パスワードを使わないよう各ユーザーに対して指示してください。
英語の単語を組み合わせたフレーズ (たとえば、beammeup)
フレーズ内の各単語の頭文字だけを集めた、意味のない文字列 (たとえば、SomeWhere Over The RainBow から取った swotrb)
文字を数字や記号に代えた単語 (たとえば、snoopy を sn00py にする)
次のものは、パスワードに不適当です。
自分の名前そのもの、逆読み、飛ばし読みのもの
家族やペットの名前
免許証番号
電話番号
社会保健番号
従業員番号
趣味や興味に関連した名前
12 月の "Santa" のように季節に関連した言葉
辞書にある単語
NIS+ または /etc 内のファイルを使用してユーザーアカウント情報を格納する場合は、ユーザーのパスワードにパスワード有効期限を設定できます。パスワード有効期限の設定によって、ユーザーに定期的なパスワード変更を強制したり、あるパスワードを保持するのに必要な最低日数以前にパスワードを変更するのを防止したりできます。不正ユーザーが、古くて使用されていないアカウントを使用して、発覚せずにシステムのアクセス権を得るような場合を防止するために、アカウントが無効になる日付けを設定することができます。
ホームディレクトリは、ユーザーが専有ファイルを格納するのに割り当てられるファイルシステムの一部分です。ホームディレクトリに割り当てる大きさは、ユーザーが作成するファイルの種類と作業によって異なります。一般的には、各ユーザーのホームディレクトリに少なくとも 15M バイトのディスク空間を割り当ててください。
ホームディレクトリは、ユーザーのローカルシステムまたはリモートファイルサーバーのどちらにでも配置できます。どちらの場合も、慣例により、ホームディレクトリは /export/home/username として作成します。大規模なサイトでは、ホームディレクトリをサーバーに格納してください。ホームディレクトリのバックアップおよび復元を容易に行うことができるようにするために、各 /export/homen ディレクトリに対して別々のファイルシステム (たとえば、/export/home1、 /export/home2 など) を使用してください。
ホームディレクトリが配置される位置に関係なく、ユーザーは通常 /home/username という名前のマウントポイントを介してホームディレクトリにアクセスします。Autofs を使用してホームディレクトリがマウントされていると、どのシステムでも /home マウントポイントの下にディレクトリを作成することは許可されません。Autofs が使用されていると、システムはマウントされている /home を特別なものと認識します。ホームディレクトリの自動マウントについての詳細は、『Solaris のシステム管理 (第 3 巻)』を参照してください。
ネットワーク上の任意の位置からホームディレクトリを使用するには、 /export/home/username ではなく、常に $HOME という環境変数の値によって参照するようにしてください。前者はマシンに固有の指定です。さらに、ユーザーのホームディレクトリで作成されるシンボリックリンクはすべて相対パス (たとえば ../../../x/y/x ) を使用する必要があります。こうすることによって、そのリンクはどのシステムにホームディレクトリがマウントされても有効になります。
ファイルを作成して格納するホームディレクトリの他に、ユーザーには仕事をするために必要なツールと資源にアクセスできる環境が必要です。ユーザーがシステムにログインするとき、C、Korn、Bourne シェルなどユーザーの起動シェルで定義される初期設定ファイルによって、ユーザーの作業環境が決定されます。
ユーザーの作業環境を管理するのに便利な方法として、カスタマイズしたユーザー初期設定ファイル (.login、.cshrc、.profile) をユーザーのホームディレクトリに置くという方法があります。ユーザー初期設定ファイルをユーザー用にカスタマイズする詳細については、「ユーザーの作業環境のカスタマイズ」を参照してください。ユーザー初期設定ファイルをカスタマイズした後、新しいユーザーアカウントを作成するときにそれらをユーザーのホームディレクトリに追加できます。
1 回だけ行う作業としてお薦めするのは、「スケルトンディレクトリ」と呼ばれる別々のディレクトリをサーバーに設定することです (ユーザーのホームディレクトリが格納されるのと同じサーバーを使用できます)。スケルトンディレクトリによって、タイプの異なるユーザーに合わせてカスタマイズしたユーザー初期設定ファイルを格納できます。
システム初期設定ファイル (/etc/profile、/etc/.login) を使用してユーザーの作業環境を管理しないでください。これらのファイルはローカルシステムに存在するため、集中管理されません。たとえば、Autofs を使用してネットワーク上の任意のシステムからユーザーのホームディレクトリをマウントした場合、ユーザーがシステム間を移動しても環境が変わらないよう保証するには、各システムでシステム初期設定ファイルを修正しなければならなくなります。
また、役割によるアクセス制御でユーザーアカウントをカスタマイズする方法もあります。詳細は、『Solaris のシステム管理 (第 2 巻)』の「役割によるアクセス制御」を参照してください。
「グループ」とは、ファイルやその他のシステム資源を共有できるユーザーの集合のことです。たとえば、同じプロジェクトで作業するユーザーはグループを構成することになります。グループは、従来の UNIX グループのことです。
各グループには、名前、グループ識別 (GID) 番号、およびそのグループに属しているユーザー名のリストが必要です。システムは GID によって内部的にグループを識別します。ユーザーは次の 2 つの種類のグループに所属できます。
ユーザーの二次グループは、場合によっては重要でないことがあります。たとえば、ファイルの所有権は、一次グループだけが関係し、二次グループは関係しません。ただし、アプリケーションによってはユーザーの二次グループが関係することがあります。たとえば、ユーザーは、Admintool ソフトウェアを使用するとき sysadmin グループ (グループ 14) のメンバーでなければなりませんが、グループ 14 がそのユーザーの現在の一次グループであるかどうかは問題にはなりません。
groups コマンドを使って、ユーザーが所属しているグループを表示できます。ユーザーは一度に 1 つの一次グループにしか所属できません。ただし、自分がメンバーとなっている他のグループに (newgrp コマンドを使用して) 一時的に一次グループを変更することはできます。
ユーザーアカウントを追加するとき、ユーザーに一次グループを割り当てるか、デフォルトの staff (グループ 10) を使用しなければなりません。一次グループは、すでに存在しているものでなければなりません (存在しない場合、GID 番号でグループを指定します)。ユーザー名は、一次グループに追加されません。追加されると、リストが長くなりすぎるからです。ユーザーを新しい二次グループに割り当てる前に、そのグループを作成し、それに GID 番号を割り当てなければなりません。
グループは、システムにとってローカルになるか、またはネームサービスを通して管理することができます。グループ管理を単純化するために、グループメンバーを集中管理できる NIS+ のようなネームサービスを使用してください。
表 2-4 に、ユーザーとグループを管理する推奨ツールを示します。
表 2-4 ユーザーとグループを管理するための推奨ツール
管理するユーザーとグループの場所 |
推奨ツール |
必要なもの |
参照先 |
---|---|---|---|
ネットワークに接続されたネームサービス (NIS、NIS+) 環境におけるリモートまたはローカル、またはその両方のシステム |
AdminSuite2.3TM のユーザーマネージャとグループマネージャ (グラフィカルユーザーインタフェース) |
CDE などの X window 環境が動作しているグラフィックモニター |
『Solstice AdminSuite 2.3 管理者ガイド』 |
ローカルシステム |
Admintool (グラフィカルユーザーインタフェース) |
CDE などの X window が動作しているグラフィックモニター |
Solaris の useradd コマンドと groupadd コマンドを使用しても、ローカルシステムのユーザーとグループを設定できます。ただし、これらのコマンドではネームサービスのマップやテーブルを変更できません。表 2-5 で、Solstice AdminSuite2.3 または Admintool を使用しない場合に、ユーザーアカウントとグループを管理する Solaris のコマンドについて説明します。
表 2-5 Solaris のコマンドを使用してユーザーアカウントとグループを管理する方法
作業 |
使用するネームサービス |
使用するコマンド |
---|---|---|
ユーザーアカウントの追加 |
NIS+ |
nistbladm nisclient |
|
NIS |
useradd make |
|
なし |
useradd |
ユーザーアカウントの変更 |
NIS+ |
nistbladm |
|
NIS |
usermod make |
|
なし |
usermod |
ユーザーアカウントの削除 |
NIS+ |
nistbladm nisclient |
|
NIS |
userdel make |
|
なし |
userdel |
ユーザーアカウントのデフォルトの設定 |
NIS+ |
なし |
|
NIS |
useradd -D make |
|
なし |
useradd -D |
ユーザーアカウントを無効にする |
NIS+ |
nistbladm |
|
NIS |
passwd -r nis -l make |
|
なし |
passwd -f iles -l |
ユーザーのパスワードの変更 |
NIS+ |
passwd -r nisplus |
|
NIS |
passwd -r nis |
|
なし |
passwd -r files |
ユーザーアカウントのソート |
NIS+ |
niscat sort |
|
NIS |
ypcat sort |
|
なし |
awk sort |
ユーザーアカウントの検索 |
NIS+ |
nismatch |
|
NIS |
ypmatch |
|
なし |
grep |
グループの追加 |
NIS+ |
nistbladm |
|
NIS |
groupadd make |
|
なし |
groupadd |
グループ内のユーザーの変更 |
NIS+ |
nistbladm |
|
NIS |
groupmod make |
|
なし |
groupmod |
グループの削除 |
NIS+ |
nistbladm |
|
NIS |
groupdel make |
|
なし |
groupdel |
Admintool はローカルシステムでユーザーアカウントを設定できるグラフィカルユーザーインタフェースです。
既存のものと重複するユーザー名や UID 番号を定義しないかぎり、ユーザーアカウントのログイン名や UID 番号を変更する必要はありません。 2 つのユーザーアカウントが、同じユーザー名または UID 番号を持つ場合、次の手順に従ってください。
2 つのユーザーアカウントが同じ UID 番号を持つ場合、Admintool を使用して、どちらか一方のアカウントを削除し、もう一度、異なる UID 番号で追加します。Admintool を使用して、既存のユーザーアカウントの UID 番号を変更することはできません。
2 つのユーザーアカウントが同じユーザー名を持つ場合、Admintool を使用して、どちらか一方のアカウントを修正し、ユーザー名を変更します。
Admintool を使用してユーザー名を変えた場合でも、ホームディレクトリの所有権は変更されます。(ユーザーのホームディレクトリが存在する場合)。
ユーザーアカウントの中で変更できる情報に、ユーザーのグループメンバシップがあります。Admintool の「変更 (Modify)」オプションで、ユーザーの二次グループを追加したり、削除したりできます。あるいは、「グループ」ウィンドウを使ってグループのメンバーリストを直接修正したりすることもできます。
ユーザーアカウントの次の部分も変更できます。
コメント
ログインシェル
パスワード
ホームディレクトリ
Admintool でユーザーアカウントを削除すると、passwd、group、ファイル内のエントリが自動的に削除されます。さらに、ユーザーのホームディレクトリにあるファイルを削除できます。
ユーザーマネージャでユーザー初期設定ファイルをカスタマイズして作成することはできませんが、指定された「スケルトン」ディレクトリ内のユーザー初期設定ファイルでユーザーのホームディレクトリを生成することができます。
/etc/skel ディレクトリにあるユーザー初期設定テンプレートをカスタマイズし、それらをユーザーのホームディレクトリへコピーできます。
Admintool を使って、次のようにパスワードを管理できます。(1) ユーザーアカウントに通常のパスワードを指定する(2) ユーザーが最初のログイン時にパスワードを作成できるようにする (3) ユーザーアカウントを無効にするかロックする (4) 有効期限とパスワード有効期限情報を指定する
パスワード有効期限は、NIS ネームサービスではサポートされません。
一時的にまたは永久に、ログインアカウントを無効にしなければならないことがあります。ユーザーアカウントを無効にしたりロックしたりすると、無効なパスワード *LK* がユーザーアカウントに割り当てられ、それ以後ログインできなくなります。
最も簡単にユーザーアカウントを無効にする方法は、Admintool を使用してアカウントのパスワードをロックすることです。また、「有効期限(Expiration Date)」フィールドに有効期限を入力して、ユーザーアカウントを無効にする期間を設定することができます。
また、パスワード有効期限を設定するかパスワードを変更することによって、ユーザーアカウントを無効にできます。
ユーザーアカウントとグループ情報は、サイトの方針に応じて、ネームサービスまたはローカルシステムの /etc 内のファイルのどちらかに格納できます。NIS+ ネームサービスでは、情報はテーブルに格納され、NIS ネームサービスではマップに格納されます。
混乱を避けるために、ユーザーアカウントとグループ情報の位置は、ファイル、テーブル、マップという 3 種類の呼び方ではなく、単にファイルと呼びます。
ほとんどのユーザーアカウント情報は、passwd ファイルに格納されます。ただし、パスワード暗号とパスワード有効期限は、NIS か NIS+ を使用するときは passwd ファイルに、/etc ファイルを使用するときは /etc/shadow ファイルに格納されます。NIS を使用するとき、パスワード有効期限は使用できません。
passwd ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。
username:password:uid:gid:comment:home-directory:login-shell
具体的な例は次のようになります。
kryten:x:101:100:Kryten Series 4000 Mechanoid:/export/home/kryten:/bin/csh
表 2-6 に、passwd ファイルの各フィールドについて説明します。
表 2-6 passwd ファイルのフィールド
フィールド名 |
説明 |
---|---|
ユーザー (またはログイン) 名。ユーザー名は固有で、 1 から 8 文字の英字 (A-Z、a-z) と数字 (0-9) を使用する。最初の文字は英字で、少なくとも 1 文字は小文字を使用する。ユーザー名には下線や空白文字は使用できない。 |
|
暗号化されたパスワードの代わりの x (パスワードフィールドはもう使用されない)。暗号化されたパスワードは shadow ファイルに格納される。 |
|
ユーザーをシステムに識別させるユーザー識別番号 (UID)。一般ユーザーの UID は 100 から 60000 までの範囲とする。UID 番号はすべて固有でなければならない。 |
|
ユーザーの一次グループのグループ識別番号 (GID)。各 GID は 0 から 60002 までの範囲の整数でなければならない (60001 と 60002 はそれぞれ nobody と noaccess に割り当てられる)。 |
|
通常はユーザーのフルネーム。 (このフィールドはコメントとしての情報専用。) このフィールドは、もともとは、Bell 研究所の UNIX システムから GECOS (General Electric Computer Operating System) を実行するメインフレームにバッチジョブを依頼する場合、必要なログイン情報を保持するために使われていたので、GCOS フィールドと呼ばれることもある。 |
|
ユーザーのホームディレクトリのパス名。 |
|
ユーザーのデフォルトログインシェル。これは /bin/sh、/bin/csh、/bin/ksh のどれかになる。表 2-13 のシェル機能の説明を参照のこと。 |
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 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:/: |
ユーザー名 |
ユーザー ID |
説明 |
---|---|---|
root |
0 |
スーパーユーザーのアカウント |
daemon |
1 |
カレンダの更新などに関連するシステム包括デーモン |
bin |
2 |
ルーチンシステムタスクを実行するシステムバイナリの実行に関連する管理デーモン |
sys |
3 |
システムのログの記録や一時ディレクトリのファイルの更新に関連する管理デーモン |
adm |
4 |
システムのログの記録に関連する管理デーモン |
|
71 |
ラインプリンタのデーモン |
uucp |
5 |
uucp デーモン |
nuucp |
6 |
uucp デーモン |
listen |
37 |
ネットワーク監視デーモン |
nobody |
60001 |
未承認の root ユーザーから要求を受信したときに NFS サーバーが割り当てる匿名ユーザー用のアカウント。nobody ユーザーアカウントは、特別なアクセス権を必要としない、あるいは持つべきではないソフトウェアプロセスに割り当てられる。 |
noaccess |
60002 |
あるアプリケーションを経由するが実際にログインをしないで、システムにアクセスする必要があるユーザーまたはプロセスに割り当てられるアカウント。 |
nobody4 |
65534 |
SunOS 4.0 または 4.1 の nobody ユーザーアカウント |
shadow ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。
username:password:lastchg:min:max:warn:inactive:expire
具体的な例は次のようになります。
rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978
表 2-8 に shadow ファイルの各フィールドについて説明します。
表 2-8 shadow ファイルのフィールド
フィールド名 |
説明 |
---|---|
ユーザー (またはログイン) 名。 |
|
次のエントリのいずれかになる。13 文字の暗号化されたユーザーパスワード。アクセス不可能なアカウントを示す *LK*。アカウントのパスワードがないことを示す NP。 |
|
1970 年 1 月 1 日から最後にパスワードを変更した日付までの日数。 |
|
パスワードの変更から次の変更までに必要な最短日数。 |
|
ユーザーが新しいパスワードの指定をもとめられるまで、パスワードを変更しないで使い続けることができる最長日数。 |
|
アカウントを使用 (ログイン) しなくてもよい最長日数。 |
|
group ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。
group-name:group-password:gid:user-list
具体的な例は次のようになります。
bin::2:root,bin,daemon
表 2-9 に group ファイルの各フィールドについて説明します。
表 2-9 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,tty,adm lp::8:root,lp,adm nuucp::9:root,nuucp staff::10: daemon::12:root,daemon sysadmin::14:root nobody::60001: noaccess::60002: nogroup::65534: |
グループ名 |
グループ ID |
説明 |
---|---|---|
root |
0 |
スーパーユーザーのグループ |
other |
1 |
|
bin |
2 |
システムバイナリの実行に関連する管理グループ |
sys |
3 |
システムのログの記録や一時ディレクトリに関連する管理グループ |
adm |
4 |
システムのログの記録に関連する管理グループ |
uucp |
5 |
uucp 機能に関連するグループ |
|
6 |
電子メールのグループ |
tty |
7 |
tty デバイスに関連するグループ |
|
8 |
ラインプリンタのグループ |
nuucp |
9 |
uucp 機能に関連するグループ |
staff |
10 |
一般的な管理グループ |
daemon |
12 |
デーモングループ |
sysadmin |
14 |
Admintool と AdminSuite に関連する管理グループ |
nobody |
60001 |
未承認の root ユーザーから要求を受信したときに NFS サーバーが割り当てる匿名グループ |
noaccess |
60002 |
|
nogroup |
65534 |
|
ユーザーのホームディレクトリの設定には、ユーザーのログインシェルにユーザー初期設定ファイルを提供することも含まれます。ユーザー初期設定ファイルは、ユーザーがシステムにログインしたあとにユーザーのために作業環境を設定するシェルスクリプトです。基本的にシェルスクリプトでできる処理はどれもユーザー初期設定ファイルで実行できますが、主に、ユーザーの検索パス、環境変数、ウィンドウ機能の環境などユーザーの作業環境を定義します。表 2-11 に示すように、各ログインシェルには、1 つまたは複数の、固有のユーザー初期設定ファイルがあります。
表 2-11 Bourne、C、Korn シェルのユーザー初期設定ファイル
シェル |
初期設定ファイル |
目的 |
---|---|---|
$HOME/.profile |
ログイン時のユーザー環境の定義
|
|
$HOME/.cshrc |
ログインシェルのあとに起動されるすべての C シェルに対するユーザー環境の定義 |
|
|
ログイン時のユーザー環境の定義
|
|
ログイン時のユーザー環境の定義 |
||
|
Korn シェルの ENV 環境変数によって指定されるファイルにおける、ログイン時のユーザー環境の定義 |
Solaris 環境には、表 2-12 に示すように、各システムの /etc/skel ディレクトリに、各シェル用のデフォルトのユーザー初期設定ファイルが提供されています。
表 2-12 デフォルトのユーザー初期設定ファイル
シェル |
デフォルトファイル |
---|---|
| |
これらのファイルを変更して、すべてのユーザーに共通な作業環境を提供する標準のファイルセットを作成したり、あるいは異なるタイプのユーザーに作業環境を提供したりすることができます。異なるタイプのユーザーにユーザー初期設定ファイルを作成する手順については、「ユーザー初期設定ファイルをカスタマイズする方法」を参照してください。
Admintool で新しいユーザーアカウントを作成して、ホームディレクトリを作成するオプションを選択すると、選択したログインシェルに合わせて次のファイルが作成されます。
シェル |
作成されるファイル |
---|---|
C |
/etc/skel/local.cshrc ファイルと /etc/skel/local.login ファイルがユーザーのホームディレクトリにコピーされ、それぞれ、.cshrc と .login という名前に変更される。 |
Bourne と Korn |
/etc/skel/local.profile ファイルがユーザーのホームディレクトリにコピーされ、.profile という名前に変更される。 |
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/machine-name/directory-name などのグローバルパス名を使用してください。システムが AutoFS を実行していれば、/net/machine-name で参照されるディレクトリはすべてユーザーがログインする任意のシステムに自動的にマウントできます。
表 2-13 に、各シェルの基本的機能を示します。ユーザー初期設定ファイルを作成するのにどのシェルがどんな機能を提供するか参考にしてください。
表 2-13 Bourne、C、Korn シェルの基本機能
機能 |
Bourne |
C |
Korn |
---|---|---|---|
UNIX で標準シェルとして知られる |
○ |
* |
* |
Bourne シェルと互換性がある構文 |
- |
* |
○ |
ジョブ制御 |
○ |
○ |
○ |
履歴リスト |
* |
○ |
○ |
コマンド行編集 |
* |
○ |
○ |
別名 (エイリアス) |
* |
○ |
○ |
ログインディレクトリの 1 文字省略形 |
* |
○ |
○ |
ファイルの上書き保護 (noclobber) |
* |
○ |
○ |
CTRL-D 無視 (ignoreeof) |
* |
○ |
○ |
拡張 cd |
* |
○ |
○ |
.profile とは別の初期設定ファイル |
* |
○ |
○ |
ログアウトファイル |
○ |
○ |
シェルは、login プログラム、システム初期設定ファイル、ユーザー初期設定ファイルによって定義される変数を含む環境を管理します。また、一部の変数はデフォルトによって定義されます。シェルには次の 2 種類の変数があります。
環境変数 - シェルによって生成されるすべてのプロセスにエクスポートされる変数。環境変数の設定値は env コマンドで表示できます。PATH などを含む環境変数の一部が、シェルそのものの動作に影響を与えます。
シェル (ローカル) 変数 - 現在使用中のシェルだけに関係する変数。C シェルの場合は、シェル変数は環境変数と特別に対応しています。これらのシェル変数は user、term、home、path です。シェル変数は、対応する環境変数の値によって初期設定されます。
C シェルでは、小文字を使って set コマンドでシェル変数を設定し、大文字を使って setenv コマンドで環境変数を設定します。シェル変数を設定すると、対応する環境変数が設定され、その逆もあります。たとえば、path シェル変数を新しいパスで更新すると、シェルは PATH 環境変数も新しいパスで更新します。
Bourne、Korn 両シェルでは、一般的に、大文字を使って setenv コマンドでシェル変数と環境変数を設定します。また、export コマンドで環境変数の設定を終了しなければなりません。すべてのシェルで、シェル変数と環境変数は一般的に大文字の名前で参照します。
ユーザー初期設定ファイルで、ユーザーのシェル環境を、あらかじめ定義された変数の値を変更するか、変数を追加することによってカスタマイズできます。表 2-14 はユーザー初期設定ファイルで環境変数を設定する方法を示します。
表 2-14 ユーザー初期設定ファイルでの環境変数の設定方法
環境変数を設定したいシェル |
ユーザー初期設定ファイルに追加する行 |
---|---|
setenv MAIL /var/mail/ripley |
|
VARIABLE=value; export VARIABLE 例: MAIL=/var/mail/ripley;export MAIL |
表 2-15 に、ユーザー初期設定ファイルでカスタマイズできる環境変数とシェル変数を説明します。各シェルで使用される変数についての詳細は、 sh(1)、 ksh(1)、 csh(1) の各マニュアルページを参照してください。
表 2-15 シェル変数と環境変数の説明
ユーザーが絶対パス名でコマンドを入力すると、シェルはそのパス名を使ってコマンドを探します。ユーザーがコマンド名しか指定しないと、シェルは PATH 変数で指定されているディレクトリの順でコマンドを探します。ディレクトリのどれかで見つかれば、シェルはコマンドを実行します。
デフォルトのパスがシステムで設定されますが、大部分のユーザーはそれを変更して他のコマンドディレクトリを追加します。環境の設定や、正しいバージョンのコマンドまたはツールへのアクセスに関連して発生するユーザーの問題の多くは、パス定義の誤りが原因です。
次に、効率的な PATH 変数を設定するガイドラインをいくつか示します。
セキュリティが特に問題とならないときは、現在の作業ディレクトリ (.) をパスの最初に指定します。しかし、現在の作業ディレクトリをパスに入れると、セキュリティ上の問題となることがあり、特にスーパーユーザーにとって問題となります。
検索パスはできるだけ短くしておきます。シェルはパスで各ディレクトリを探します。コマンドが見つからないと、検索に時間がかかり、システムのパフォーマンスが低下します。
検索パスは左から右に読まれるため、通常使用するコマンドをパスの初めの方に指定するようにしてください。
パスでディレクトリを重複しないように確認してください。
可能であれば、大きなディレクトリの検索は避けてください。大きなディレクトリはパスの終わりに指定します。
NFS サーバーが応答しないときに「ハング」の可能性を少なくしたり、不要なネットワークトラフィックを削減するよう、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 変数、LC_COLLATE、LC_CTYPE、 LC_MESSAGES、LC_NUMERIC、 LC_MONETARY、LC_TIME によってその他の設定を行えます。
表 2-16 は、LANG と LC 環境変数の値の一部を示します。
表 2-16 LANG と LC 変数の値
値 |
ロケール |
---|---|
de |
German |
fr |
French |
English および European |
|
it |
Italian |
japanese |
Japanese |
korean |
Korean |
sv |
Swedish |
tchinese |
Taiwanese |
次の例は、LANG 環境変数を使ってロケールを設定する方法を示しています。C シェルユーザー初期設定ファイルでは、次の行を追加してください。
setenv LANG DE
Bourne または Korn シェルユーザー初期設定ファイルでは、次の行を追加してください。
LANG=DE; export LANG
ファイルまたはディレクトリを作成したときに設定されるデフォルトのファイルアクセス権は、ユーザーマスクによって制御されます。ユーザーマスクは、初期設定ファイルで umask コマンドによって設定されます。現在のユーザーマスクの値は、umask と入力して Return キーを押すと表示できます。
ユーザーマスクは 3 桁の 8 進値で設定します。最初の桁でそのユーザーのアクセス権を設定し、第 2 桁でグループのアクセス権を設定し、第 3 桁で「その他 」(ワールドとも呼ばれます) のアクセス権を設定します。最初の桁がゼロの場合、この桁は表示されません。たとえば、umask を 022 に設定すると、22 が表示されます。
設定する umask の値は、与えたいアクセス権の値を 666 (ファイルの場合) または 777 (ディレクトリの場合) から引きます。引いた残りが umask に使用する値です。たとえば、ファイルのデフォルトモードを 644 (rw-r--r--) に変更したいとすれば、666 と 644 の差 022 が umask コマンドの引数として使用する値です。
また、表 2-17 から umask 値を決めることもできます。この表は、 umask の各 8 進値から作成される、ファイルとディレクトリのアクセス権を示します。
表 2-17 umask 値のアクセス権
umask 8 進値 |
ファイルアクセス権 |
ディレクトリアクセス権 |
---|---|---|
0 |
rw- |
rwx |
1 |
rw- |
rw- |
2 |
r-- |
r-x |
3 |
r-- |
r-- |
4 |
-w- |
-wx |
5 |
-w- |
-w- |
6 |
--x |
--x |
7 |
--- (なし) |
--- (なし) |
次の例は、デフォルトのファイルアクセス権を rw-rw-rw- に設定します。
umask 000
ここでは、ユーザー自身の初期設定ファイルをカスタマイズする場合にまず使用する、ユーザー初期設定ファイルとサイト初期設定ファイルの例を示します。例の中のシステム名やパス名は、実際のサイトに合わせて置き換えてください。
PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:. 1 MAIL=/var/mail/$LOGNAME 2 NNTPSERVER=server1 3 MANPATH=/usr/share/man:/usr/local/man 4 PRINTER=printer1 5 umask 022 6 export PATH MAIL NNTPSERVER MANPATH PRINTER 7 |
ユーザーのシェル検索パスを設定する。
ユーザーのメールファイルへのパスを設定する。
ユーザーの Usenet ニュースサーバーを設定する。
マニュアルページへのユーザーの検索パスを設定する。
ユーザーのデフォルトプリンタを設定する。
ユーザーのデフォルトのファイル作成アクセス権を設定する。
指定された環境変数をエクスポートする。
set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin) 1 setenv MAIL /var/mail/$LOGNAME 2 setenv NNTPSERVER server1 3 setenv PRINTER printer1 4 alias h history 5 umask 022 6 source /net/server2/site-init-files/site.login 7 |
ユーザーのシェル検索パスを設定する。
ユーザーのメールファイルへの検索パスを設定する。
ユーザーの Usenet ニュースサーバーを設定する。
ユーザーのデフォルトプリンタを設定する。
history コマンドの別名を作成する (h と入力するだけで history コマンドを実行できる)。
ユーザーのデフォルトのファイル作成アクセス権を設定する。
指定された環境変数をエクスポートする。
次のサイト初期設定ファイルの例では、ユーザーは特定のバージョンのアプリケーションを選択できます。
# @(#)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 という名前のサーバー上にあります。また、自動マウンタがユーザーのシステムで実行されていることを前提としています。