この章では、ユーザーアカウントとグループを管理するためのガイドラインと管理計画の概要について説明します。また、ユーザーの作業環境のカスタマイズについても説明します。
この章の内容は次のとおりです。
ユーザーアカウントとグループの管理手順については、第 5 章ユーザーアカウントとグループの管理 (手順)を参照してください。
この節では、この Oracle Solaris リリースで新たに追加または変更された、ユーザーとグループの管理機能について説明します。
この Solaris リリースで新たに追加または変更された機能はありません。
新機能の完全な一覧や各 Oracle Solaris リリースの説明については、『Oracle Solaris 10 9/10 の新機能』を参照してください。
次の表に、ユーザーアカウントとグループの管理に使用できるツールを示します。
表 4–1 ユーザーアカウントとグループの管理用のツール
ツール名 |
説明 |
詳細 |
---|---|---|
Solaris 管理コンソール |
ユーザー、グループ、役割、権利、メーリングリスト、ディスク、端末、およびモデムを管理するためのグラフィカルツール。 | |
smuser、smrole、smgroup |
ユーザー、グループ、および役割を管理するためのコマンド。これらのコマンドを使用するには、SMC サービスを実行しておく必要があります。 | |
useradd、groupadd、roleadd、usermod、groupmod、rolemod、userdel、groupdel、roledel |
ユーザー、グループ、および役割を管理するためのコマンド。 |
次のツールを使ってグループを追加できます。
Solaris 管理コンソールのグループツール
Admintool
この Solaris リリースでは Admintool は使用できません。
コマンド |
説明 |
参照ページ |
---|---|---|
useradd、usermod、userdel |
ユーザーを追加、変更、削除します | |
groupadd、groupmod、groupdel |
グループを追加、変更、削除します |
基本的なシステム管理作業の 1 つに、サイトの各ユーザーにユーザーアカウントを設定することがあります。通常のユーザーアカウントには、ユーザーがスーパーユーザーのパスワードを知らなくても、システムにログインして、システムを使用するのに必要な情報が含まれています。ユーザーアカウント情報の構成要素については、「ユーザーアカウントの構成要素」で説明します。
ユーザーアカウントを設定するときに、ユーザーをあらかじめ定義されたユーザーグループに追加できます。グループは一般に、ファイルまたはディレクトリへのグループアクセス権を設定して、グループ内のユーザーだけがファイルとディレクトリにアクセスできるようにするために使用されます。
たとえば、ごく少数のユーザーだけにアクセスさせたい機密ファイルを入れるディレクトリを作成できます。topsecret プロジェクトに携わるユーザーを含む topsecret という名前のグループを設定します。そして、topsecret ファイルの読み取り権を topsecret グループに対して設定します。こうすれば、topsecret グループ内のユーザーだけが、ファイルを読み取ることができます。
また、「役割」という特別な種類のユーザーアカウントは、指定したユーザーに特別な特権を与えるときに使用します。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。
次の節では、ユーザーアカウントのそれぞれの構成要素について説明します。
ユーザーは、ユーザー名 (ログイン名とも呼ばれる) を使って、適切なアクセス権を持つ自分のシステムとリモートシステムにアクセスできます。作成するユーザーアカウントそれぞれに、ユーザー名を選択しなければなりません。
ユーザー名を探しやすいように、ユーザー名の標準的な割り当て方法を使用することを検討してください。また、ユーザー名はユーザーが覚えやすいものにしてください。単純な規則の例としては、ユーザーのファーストネームの頭文字とラストネームの最初の 7 文字を使用します。たとえば、Ziggy Ignatz は zignatz になります。ほかのユーザー名と重複する場合は、ユーザーのファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 6 文字を使用します。たとえば、Ziggy Top Ignatz は ztignatz になります。
さらに重複する場合、ユーザー名の作成には次の方法を検討してください。
ファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 5 文字を使用します
固有の名前になるまで 1、2、3 などの数字を使用します
それぞれの新しいユーザー名は、システムまたは NIS ドメインに登録されているどのメール別名 (エイリアス) とも異なるものでなければなりません。そうしないと、メールは実際のユーザーにではなく別名に送られることがあります。
ユーザー (ログイン) 名の設定方法の詳しいガイドラインについては、「ユーザー名、ユーザー ID、およびグループ ID を使用するガイドライン」を参照してください。
ユーザー名に関連するものとして、ユーザー識別 (UID) 番号があります。ユーザーがログインしようとするシステムは、UID 番号によってユーザー名を識別したり、ファイルとディレクトリの所有者を識別したりします。多数の異なるシステム上で、ある個人用にユーザーアカウントを作成する場合は、常に同じユーザー名と ID 番号を使用してください。そうすれば、そのユーザーは、所有権の問題を起こすことなく、システム間で簡単にファイルを移動できます。
UID 番号は、2147483647 以下の整数でなければなりません。UID 番号は、通常のユーザーアカウントと特殊なシステムアカウントに必要です。次の表に、ユーザーアカウントとシステムアカウントに予約されている UID 番号を示します。
表 4–3 予約済みの UID 番号
UID 番号 |
ユーザー/ログインアカウント |
説明 |
---|---|---|
0 - 99 |
root、daemon、bin、sys など |
Oracle Solaris 用に予約 |
100 - 2147483647 |
通常のユーザー |
汎用アカウント |
60001 と 65534 |
nobody および nobody4 |
匿名ユーザー |
60002 |
noaccess |
アクセス権のないユーザー |
0 - 99 の UID 番号を割り当てないでください。これらの UID は、Oracle Solaris による割り当て用に予約されています。システム上の定義により、root には常に UID 0、daemon には UID 1、擬似ユーザー bin には UID 2 が設定されます。また、UID が passwd ファイルの先頭にくるように、uucp ログインや、who、tty、ttytype などの擬似ユーザーログインには低い UID を指定するようにしてください。
UID の設定方法の詳しいガイドラインについては、「ユーザー名、ユーザー ID、およびグループ ID を使用するガイドライン」を参照してください。
ユーザー (ログイン) 名と同様に、固有の UID 番号を割り当てる方法を決めてください。企業によっては、従業員に固有の番号を割り当て、管理者がその従業員番号にある番号を加えて固有の UID 番号を作成している場合もあります。
セキュリティー上のリスクを最小限に抑えるため、削除したアカウントの UID を再利用することは避けてください。 どうしても UID を再利用する必要がある場合、はじめから作りなおして、新しいユーザーが前のユーザーの属性に影響されないようにしてください。たとえば、前のユーザーがプリンタの拒否リストに含まれていたためプリンタにアクセスできなかった場合、その属性を新しいユーザーに適用することが正しいとは限りません。
UID とグループ ID (GID) には、符号付き整数の最大値 (つまり 2147483647) までの数値を割り当てることができます。
ただし、60000 より大きな数値の UID と GID は機能的に完全でなく、多くの Oracle Solaris の機能と互換性がありません。したがって、60000 を超える UID と GID は使わないようにしてください。
次の表では、Oracle Solaris 製品と以前のリリースとの相互運用性に関する問題について説明します。
表 4–4 60000 より大きな数値の UID または GID の相互運用性に関する問題
カテゴリ |
製品またはコマンド |
問題 |
---|---|---|
NFS 互換性 |
SunOS 4.0 NFS ソフトウェアとその互換リリース |
NFS サーバーとクライアントのコードは、大きな UID と GID を 16 ビットに切り捨てます。この状況では、SunOS 4.0 およびその互換リリースが動作しているシステムが、大きな UID と GID を使用している環境で使用されると、セキュリティーの問題が発生する可能性があります。この問題を回避するには、SunOS 4.0 およびその互換リリースが動作しているシステムにパッチをあてる必要があります。 |
ネームサービスの互換性 |
NIS ネームサービスおよびファイルベースのネームサービス |
60000 より大きな数値の UID を持つユーザーは、Solaris 2.5 (およびその互換リリース) が動作しているシステムでは、ログインしたり、su コマンドを使用したりできますが、そのユーザーの UID と GID は 60001(nobody) に設定されます。 |
NIS+ ネームサービス |
60000 より大きな数値の UID を持つユーザーは、Solaris 2.5 (およびその互換リリース) と NIS+ ネームサービスが動作しているシステムではアクセスが拒否されます。 |
次の表に、UID と GUI の制限事項を示します。
表 4–5 大きな UID および GID の制限の要約
「グループ」とは、ファイルやその他のシステム資源を共有できるユーザーの集合のことです。たとえば、同じプロジェクトで作業するユーザーはグループを構成することになります。グループは、従来の UNIX グループのことです。
各グループには、名前、グループ識別 (GID) 番号、およびそのグループに属しているユーザー名のリストが必要です。システムは GID 番号によって内部的にグループを識別します。
ユーザーは次の 2 つの種類のグループに所属できます。
一次グループ – オペレーティングシステムが、ユーザーによって作成されたファイルに割り当てるグループです。各ユーザーは、1 つの一次グループに所属していなければなりません。
二次グループ – ユーザーが所属する 1 つまたは複数のグループです。ユーザーは、最大 15 個の二次グループに所属できます。
グループ名の設定方法の詳しいガイドラインについては、「ユーザー名、ユーザー ID、およびグループ ID を使用するガイドライン」を参照してください。
ユーザーの二次グループは、場合によっては重要でないことがあります。たとえば、ファイルの所有権は、一次グループだけが反映し、二次グループは反映しません。ただし、アプリケーションによってはユーザーの二次グループが関係することがあります。たとえば、ユーザーは以前の Solaris リリースで Admintool ソフトウェアを使用するとき sysadmin グループ (グループ 14) のメンバーでなければなりませんが、グループ 14 がそのユーザーの現在の一次グループであるかどうかは問題にはなりません。
groups コマンドを使用すると、ユーザーが所属しているグループのリストを表示できます。ユーザーは一度に 1 つの一次グループにしか所属できません。ただし、newgrp コマンドを使用して、ユーザーがメンバーとなっているほかのグループに一時的に一次グループを変更することはできます。
ユーザーアカウントを追加するときは、ユーザーに一次グループを割り当てるか、デフォルトの staff グループ (グループ 10) を使用する必要があります。一次グループは、すでに存在しているものでなければなりません。存在しない場合は、GID 番号でグループを指定します。ユーザー名は、一次グループに追加されません。ユーザー名が一次グループに追加されると、リストが長くなりすぎるからです。ユーザーを新しい二次グループに割り当てる前に、そのグループを作成し、それに GID 番号を割り当てなければなりません。
グループは、システムにとってローカルにすることも、ネームサービスを介して管理することもできます。グループ管理を簡単に行うには、NIS などのネームサービスや LDAP などのディレクトリサービスを使用する必要があります。これらのサービスを使用すると、グループのメンバーを一元管理できます。
ユーザーを追加するときにそのユーザーのパスワードを指定できます。または、ユーザーが最初にログインするときにパスワードを指定するよう強制できます。
ユーザーのパスワードは、次の構文に準拠している必要があります。
パスワード長は、/etc/default/passwd ファイル内の PASSLENGTH 変数に指定された値に一致している必要があります。PASSLENGTH にはデフォルトで 6 が設定されています。
パスワードの最初の 6 文字には、2 文字以上の英字と 1 文字以上の数字または特殊文字を含める必要があります。
最大パスワード長を 9 文字以上に増やすには、9 文字以上に対応しているアルゴリズムで /etc/policy.conf ファイルを構成します。
ユーザー名は公表されますが、パスワードを知っているのは各ユーザーだけでなければなりません。各ユーザーアカウントには、パスワードを割り当てる必要があります。パスワードには、6 - 8 文字の英数字と特殊文字を組み合わせることができます。
コンピュータシステムのセキュリティーを強化するには、ユーザーのパスワードを定期的に変更する必要があります。高いレベルのセキュリティーを確保するには、ユーザーに 6 週間ごとにパスワードを変更するよう要求してください。低いレベルのセキュリティーなら、3 ヵ月に 1 度で十分です。システム管理用のログイン (root や sys など) は、毎月変更するか、root のパスワードを知っている人が退職したり交替したりするたびに変更してください。
コンピュータセキュリティーが破られる原因の多くは、正当なユーザーのパスワードが解読される場合です。ユーザーについて何か知っている人が簡単に推測できるような固有名詞、名前、ログイン名、パスワードを使わないよう各ユーザーに対して指示してください。
良いパスワードの例としては次のようなものが考えられます。
単語を組み合わせたフレーズ (たとえば、beammeup)。
フレーズ内の各単語の頭文字だけを集めた、意味のない文字列 。たとえば、SomeWhere Over The RainBow から取った swotrb。
文字を数字や記号に代えた単語。たとえば、snoopy から文字を代えた sn00py。
次のものは、パスワードに不適当です。
自分の名前そのもの、逆読み、飛ばし読みのもの
家族やペットの名前
免許証番号
電話番号
社会保険番号
従業員番号
趣味や興味に関連した単語
季節に関係のある名前 (たとえば 12 月に Santa を使うなど)
辞書にある単語
ホームディレクトリは、ユーザーが独自のファイルを格納するのに割り当てられるファイルシステムの一部分です。ホームディレクトリに割り当てる大きさは、ユーザーが作成するファイルの種類、サイズ、および数によって異なります。
ホームディレクトリは、ユーザーのローカルシステムまたはリモートファイルサーバーのどちらにでも配置できます。どちらの場合も、慣例により、ホームディレクトリは /export/home/username として作成します。大規模なサイトでは、ホームディレクトリをサーバーに格納してください。ホームディレクトリのバックアップおよび復元を簡単にするには、/export/homen ディレクトリごとに別々のファイルシステムを使用してください。たとえば、/export/home1 と /export/home2 を使用します。
ホームディレクトリが配置される場所に関係なく、ユーザーは通常 /home/username という名前のマウントポイントを介してホームディレクトリにアクセスします。Autofs を使用してホームディレクトリがマウントされていると、どのシステムでも /home マウントポイントの下にディレクトリを作成することは許可されません。Autofs が使用されていると、システムはマウントされている /home を特別なものと認識します。ホームディレクトリを自動マウントする方法については、『Solaris のシステム管理 (ネットワークサービス)』の「autofs 管理作業の概要」を参照してください。
ネットワーク上の任意の場所からホームディレクトリを使用するには、/export/home/username ではなく、常に $HOME という環境変数の値によって参照するようにしてください。前者はマシンに固有の指定です。さらに、ユーザーのホームディレクトリで作成されるシンボリックリンクはすべて相対パス (たとえば ../../../x/y/x) を使用する必要があります。こうすることによって、そのリンクはどのシステムにホームディレクトリがマウントされても有効になります。
大規模サイトのユーザーアカウントを管理する場合は、LDAP、NIS、NIS+ などのネームサービスまたはディレクトリサービスの利用を検討することをお勧めします。ネームサービスまたはディレクトリサービスを使うと、ユーザーアカウント情報を各システムの /etc 内のファイルに格納するのではなく、一元管理できます。ユーザーアカウントにネームサービスまたはディレクトリサービスを使用すると、サイト全体のユーザーアカウント情報をシステムごとにコピーしなくても、同じユーザーアカウントのままシステム間を移動できます。ネームサービスまたはディレクトリサービスを使用すると、ユーザーアカウント情報を集中化および一元化して管理できます。
ファイルを作成して格納するホームディレクトリのほかに、ユーザーには仕事をするために必要なツールとリソースにアクセスできる環境が必要です。ユーザーがシステムにログインすると、初期設定ファイルによってユーザーの作業環境が決定されます。これらのファイルは、ユーザーの起動シェルによって定義されます。起動シェルはリリースによって異なる可能性があります。
ユーザーの作業環境を管理するのに便利な方法として、カスタマイズしたユーザー初期設定ファイル (.login、.cshrc、.profile など) をユーザーのホームディレクトリに置くという方法があります。
システム初期設定ファイル (/etc/profile または /etc/.login) を使用してユーザーの作業環境を管理しないでください。これらのファイルはローカルシステムに存在するため、一元管理されません。たとえば、Autofs を使用してネットワーク上の任意のシステムからユーザーのホームディレクトリをマウントした場合、ユーザーがシステム間を移動しても環境が変わらないよう保証するには、各システムでシステム初期設定ファイルを修正しなければならなくなります。
ユーザー初期設定ファイルをユーザー用にカスタマイズする方法については、「ユーザーの作業環境のカスタマイズ」を参照してください。
また、役割によるアクセス制御 (RBAC) でユーザーアカウントをカスタマイズする方法もあります。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。
ユーザー名、UID、および GID は、複数のドメインにまたがることもあるユーザーの組織内で一意でなければなりません。
ユーザー名または役割名、UID、および GID を作成するときは、次のガイドラインに従ってください。
ユーザー名 – 2 - 8 文字の英数字を使用する必要があります。最初の文字は英字でなければならず、少なくとも 1 文字は小文字にする必要があります。
ユーザー名にはピリオド (.)、下線 (_)、ハイフン (-) を使用できますが、これらの文字により障害が発生するソフトウェアもあるため、使用はお勧めできません。
システムアカウント – デフォルトの /etc/passwd および /etc/group ファイルに含まれているユーザー名、UID、または GID を使用しないでください。0 - 99 の UID と GID は使用しないでください。これらの番号は、Oracle Solaris OS による割り当て用に予約されており、どのユーザーも使用してはいけません。この制限は、現在使用されていない番号にも適用されます。
たとえば、gdm は GNOME ディスプレイマネージャーデーモン用に予約されたユーザー名とグループ名であるため、ほかのユーザーは使用できません。デフォルトの /etc/passwd と /etc/group のエントリの全リストについては、表 4–6 と表 4–7 を参照してください。
nobody と nobody4 のアカウントは、プロセスの実行には使用しないでください。これらの 2 つのアカウントは NFS 用に予約されています。これらのアカウントをプロセスの実行に使用すると、予期しないセキュリティー上のリスクにさらされる可能性があります。root 以外のユーザーとして実行する必要があるプロセスでは、daemon または noaccess のアカウントを使用してください。
システムアカウントの設定 – デフォルトのシステムアカウントの設定は絶対に変更しないでください。この設定には、現在ロックされているシステムアカウントのログインシェルの変更が含まれています。ただし、root アカウントのパスワードとパスワード有効期限のパラメータ設定だけはこの規則に当てはまりません。
ユーザーアカウントとグループ情報は、サイトの方針に応じて、次のようにローカルシステムの /etc ファイル、ネームサービス、またはディレクトリサービスに格納されます。
NIS+ ネームサービス情報はテーブルに格納されます。
NIS ネームサービス情報はマップに格納されます。
LDAP ディレクトリサービス情報はインデックス付きのデータベースファイルに格納されます。
混乱を避けるために、ユーザーアカウントとグループ情報の格納場所は、「データベース」、「テーブル」、「マップ」という 3 種類の呼び方ではなく、単に「ファイル」と呼びます。
ほとんどのユーザーアカウント情報は、passwd ファイルに格納されます。パスワード情報は次のように格納されます。
NIS または NIS+ を使用するときは passwd ファイルに
/etc ファイルを使用するときは、/etc/shadow ファイルに
LDAP を使用するときは、people コンテナに
パスワード有効期限は、NIS+ または LDAP を使用するときは利用できますが、NIS を使用するときは利用できません。
NIS、NIS+、および files の場合、グループ情報は group ファイルに格納されます。LDAP の場合、グループ情報は group コンテナに格納されます。
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(1) のマニュアルページを参照してください。
デフォルトの passwd ファイルには、標準のデーモン用のエントリが入っています。デーモンとは、通常ブート時に起動され、システム全体で有効な操作 (印刷、ネットワーク管理、ポートの監視など) を実行するプロセスのことです。
root:x:0:0: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: gdm:x:50:50:GDM Reserved UID:/: webservd:x:80:80:WebServer Reserved UID:/: postgres:x:90:90:PostgreSQL Reserved UID:/:/usr/bin/pfksh unknown:x:96:96:Unknown Remote UID:/: svctag:x:95:12:Service Tag UID:/: nobody:x:60001:60001:NFS Anonymous Access User:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: |
ユーザー名 |
ユーザー ID |
説明 |
---|---|---|
root |
0 |
スーパーユーザーのアカウント |
デーモン |
1 |
ルーチンシステムタスクに関連するシステム包括デーモン |
bin |
2 |
ルーチンシステムタスクを実行するシステムバイナリの実行に関連する管理デーモン |
sys |
3 |
システムのログの記録や一時ディレクトリのファイルの更新に関連する管理デーモン |
adm |
4 |
システムのログの記録に関連する管理デーモン |
lp |
71 |
ラインプリンタのデーモン |
uucp |
5 |
uucp 関数に関連するデーモン |
nuucp |
6 |
uucp 関数に関連する別のデーモン |
smmsp |
25 |
Sendmail メッセージ送信プログラムデーモン |
webservd |
80 |
WebServer アクセス用に予約されたアカウント |
postgres |
90 |
PostgresSQL アクセス用に予約されたアカウント |
unknown |
96 |
NFSv4 ACL のマップ不能なリモートユーザー用に予約されたアカウント |
svctag |
95 |
サービスタグレジストリアクセス |
gdm |
50 |
GNOME ディスプレイマネージャーデーモン |
listen |
37 |
ネットワーク監視デーモン |
nobody |
60001 |
匿名の NFS アクセス用に予約されたアカウント |
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 |
shadow ファイルのフィールドの完全な説明については、shadow(4) と crypt(1) のマニュアルページを参照してください。
group ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。
group-name:group-password:gid:user-list |
次に例を示します。
bin::2:root,bin,daemon |
group ファイルのフィールドの完全な説明については、group(4) のマニュアルページを参照してください。
デフォルトの group ファイルには、システム全体に有効な操作 (印刷、ネットワーク管理、電子メールなど) をサポートする次のようなシステムグループが記述されています。これらのグループの多くは、passwd ファイルのエントリに対応しています。
root::0: other::1:root bin::2:root,daemon sys::3:root,bin,adm adm::4:root,daemon uucp::5:root mail::6:root tty::7:root,adm lp::8:root,adm nuucp::9:root staff::10: daemon::12:root sysadmin::14: smmsp::25: gdm::50: webservd::80: postgres::90: unknown::96: nobody::60001: noaccess::60002: nogroup::65534: |
グループ名 |
グループ ID |
説明 |
---|---|---|
root |
0 |
スーパーユーザーのグループ |
other |
1 |
オプションのグループ |
bin |
2 |
システムバイナリの実行に関連する管理グループ |
sys |
3 |
システムのログの記録や一時ディレクトリに関連する管理グループ |
adm |
4 |
システムのログの記録に関連する管理グループ |
uucp |
5 |
uucp 関数に関連するグループ |
|
6 |
電子メールのグループ |
tty |
7 |
tty デバイスに関連するグループ |
lp |
8 |
ラインプリンタのグループ |
nuucp |
9 |
uucp 関数に関連するグループ |
staff |
10 |
一般的な管理グループ |
デーモン |
12 |
ルーチンシステムタスクに関連するグループ |
sysadmin |
14 |
従来の Admintool と Solstice AdminSuite ツールに関連する管理グループ |
smmsp |
25 |
Sendmail メッセージ送信プログラム用のデーモン |
gdm |
50 |
GNOME ディスプレイマネージャーデーモン用に予約されたグループ |
webservd |
80 |
WebServer アクセス用に予約されたグループ |
postgres |
90 |
PostgresSQL アクセス用に予約されたグループ |
unknown |
96 |
NFSv4 ACL のマップ不能なリモートグループ用に予約されたグループ |
nobody |
60001 |
匿名の NFS アクセス用に割り当てられたグループ |
noaccess |
60002 |
あるアプリケーションを経由するが実際にログインをせずに、システムにアクセスする必要があるユーザーまたはプロセスに割り当てられるグループ |
nogroup |
65534 |
既知のグループのメンバーでないユーザーに割り当てられるグループ |
次の表に、ユーザーとグループを管理するための推奨ツールを示します。これらのツールは、Solaris 管理コンソールツール群に含まれています。Solaris 管理コンソールの起動および使用方法については、第 2 章Solaris 管理コンソールの操作 (手順)を参照してください。
表 4–8 ユーザーとグループを管理するためのツール
Solaris 管理ツール |
目的 |
---|---|
ユーザー |
ユーザーアカウントを管理します |
ユーザーテンプレート |
学生、技術者、教師のように特定のユーザーの属性セットを作成します |
権限 |
RBAC 権限を管理します |
管理役割 |
RBAC の管理役割を管理します |
グループ |
グループ情報を管理します |
プロジェクト |
プロジェクト情報を管理します |
メーリングリスト |
メーリングリストを管理します |
これらの作業の実行方法については、Solaris 管理コンソールのオンラインヘルプを参照してください。
ユーザーアカウントとグループの管理に使用できる Solaris コマンドについては、表 1–5 を参照してください。これらのコマンドは、認証およびネームサービスサポートを含め、Solaris 管理ツールと同じ機能を提供します。
Solaris ユーザー管理ツールを使用すると、ローカルシステムまたはネームサービス環境のユーザーアカウントとグループを管理できます。
次の表で、ユーザーツールのユーザーアカウント機能を使って実行可能な作業について説明します。
表 4–9 ユーザーアカウントツールの作業の説明
作業 |
説明 |
---|---|
ユーザーを追加します。 |
ユーザーをローカルシステムまたはネームサービスに追加します。 |
ユーザーテンプレートを作成します。 |
学生、契約者、技術者など、同じグループのユーザーを作成するために、定義済みのユーザー属性のテンプレートを作成します。 |
ユーザーテンプレートを使用してユーザーを追加します。 |
テンプレートを使って、定義済みのユーザー属性を使用してユーザーを追加します。 |
ユーザーテンプレートを複製します。 |
定義済みのユーザー属性を少しだけ変更して使用する場合は、ユーザーテンプレートを複製します。次に、必要な属性のみを変更します。 |
ユーザープロパティーを設定します。 |
ユーザーを追加する前にユーザープロパティーを設定します。プロパティーには、ユーザーの追加時にユーザーテンプレートを使用するかどうかや、ユーザーの削除時にデフォルトでホームディレクトリやメールボックスを削除するかどうかなどの指定があります。 |
複数ユーザーを追加します。 |
テキストファイルを指定する、それぞれの名前を入力する、または自動的に一連のユーザー名を生成することにより、ローカルシステムまたはネームサービスに複数のユーザーを追加します。 |
ユーザープロパティーを表示または変更します。 |
ログインシェル、パスワード、またはパスワードオプションなどのユーザープロパティーを表示または変更します。 |
ユーザーに権限を割り当てます。 |
特定の管理作業の実行を許可する RBAC 権限をユーザーに割り当てます。 |
ユーザーを削除します。 |
ユーザーをローカルシステムまたはネームサービスから削除します。オプションで、ユーザーのホームディレクトリまたはメールボックスも削除するかどうかを指定できます。ユーザーは、グループまたは役割からも削除されます。 |
ユーザーをローカルシステムまたはネームサービスに追加する方法については、「ユーザーアカウントとグループとは」および 「ユーザーアカウントの構成要素」を参照してください。
表 4–10 権限ツールの作業の説明
作業 |
説明 |
---|---|
権限の付与。 |
管理者だけが実行できた特定のコマンドまたはアプリケーションの実行権限をユーザーに付与します。 |
既存の権限のプロパティーの表示および変更。 |
既存の権限を表示または変更します。 |
承認の追加。 |
承認、つまり役割またはユーザーに個別に付与できる権限を追加します。 |
承認の表示および変更。 |
既存の承認を表示または変更します。 |
ユーザーに権限を付与する方法については、『Solaris のシステム管理 (セキュリティサービス)』の「権利プロファイルの内容」を参照してください。
表 4–11 管理役割ツールの作業の説明
作業 |
説明 |
---|---|
管理の役割の追加。 |
RBAC の承認役割を追加します。 |
管理の役割への権限の割り当て。 |
作業を実行できるように、役割に特定の権限を割り当てます。 |
管理の役割の変更。 |
役割に権限を追加したり、役割から権限を削除したりします。 |
管理役割の使用方法については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の実装を計画する方法」を参照してください。
表 4–12 グループツールの作業の説明
作業 |
説明 |
---|---|
グループを追加します。 |
ユーザーを追加する前にグループ名を使用できるように、ローカルシステムまたはネームサービスにグループを追加します。 |
グループにユーザーを追加します。 |
グループが所有するファイルにユーザーがアクセスする場合、ユーザーをグループに追加します。 |
グループからユーザーを削除します。 |
ユーザーがグループファイルにアクセスする必要がなくなった場合、グループからユーザーを削除します。 |
ユーザーをグループに追加する方法については、「UNIX グループ」を参照してください。
表 4–13 メーリングリストツールの作業の説明
作業 |
説明 |
---|---|
メーリングリストの作成。 |
メーリングリスト (電子メールのメッセージの宛先のリスト) を作成します。 |
メーリングリスト名の変更。 |
メーリングリストの作成後、その内容を変更します。 |
メーリングリストの削除。 |
不要になったメーリングリストを削除します。 |
メーリングリストの作成方法については、Solaris 管理コンソールのオンラインヘルプを参照してください。
表 4–14 プロジェクトツールの作業の説明
作業 |
説明 |
---|---|
プロジェクトを作成または複製します。 |
新しいプロジェクトを作成するか、新しいプロジェクトに必要な属性が酷似している既存のプロジェクトがある場合は、そのプロジェクトを複製します。 |
プロジェクト属性の変更または表示します。 |
既存のプロジェクト属性を表示または変更します。 |
プロジェクトを削除します。 |
不要になったプロジェクトを削除します。 |
ユーザーおよびグループを「プロジェクト」(システム使用率またはリソースアロケーションチャージバックの基礎として使用される、作業負荷の構成要素を示す識別子) のメンバーにすることができます。プロジェクトは、Solaris リソース管理機能の一部で、システムリソースの管理に使用されます。
Solaris 9 リリースを実行するシステムにログインするには、ユーザーはプロジェクトのメンバーになる必要があります。デフォルトでは、ユーザーは Solaris 9 リリースのインストール時に group.staff プロジェクトのメンバーになり、ほかのプロジェクト情報は設定されていません。
ユーザーのプロジェクト情報は、/etc/project ファイルに格納され、このファイルは、ローカルシステム (ファイル)、NIS ネームサービス、または LDAP ディレクトリサービスに保存できます。Solaris 管理コンソールを使用すると、プロジェクト情報を管理できます。
/etc/project ファイルは、ユーザーがログインするために必要ですが、プロジェクトを使用しない場合は管理する必要はありません。
プロジェクトの使用方法および設定方法については、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の第 2 章「プロジェクトとタスク (概要)」を参照してください。
ユーザーのホームディレクトリの設定には、ユーザーのログインシェルにユーザー初期設定ファイルを提供することも含まれます。ユーザー初期設定ファイルは、ユーザーがシステムにログインしたあとにユーザーのために作業環境を設定するシェルスクリプトです。基本的にシェルスクリプトで行える処理はどれもユーザー初期設定ファイルで実行できます。主に、ユーザーの検索パス、環境変数、ウィンドウ機能の環境など、ユーザーの作業環境を定義します。次の表に示すように、各ログインシェルには、1 つまたは複数の、固有のユーザー初期設定ファイルがあります。
表 4–15 Bourne、C、Korn シェルのユーザー初期設定ファイル
シェル |
初期設定ファイル |
目的 |
---|---|---|
Bourne |
$HOME/.profile |
ログイン時のユーザー環境を定義します |
$HOME/.cshrc |
すべての C シェルに対するユーザー環境の定義で、ログインシェルのあとに起動されます |
|
|
ログイン時のユーザー環境を定義します
|
|
ログイン時のユーザー環境を定義します |
||
|
$HOME/$ENV |
ログイン時のユーザー環境の定義で、Korn シェルの ENV 環境変数によって指定されます |
表 4–16 デフォルトのユーザー初期設定ファイル
シェル |
デフォルトファイル |
---|---|
| |
これらのファイルを変更して、すべてのユーザーに共通の作業環境を提供する標準のファイルセットを作成できます。異なるタイプのユーザーごとに作業環境を提供する場合にも、これらのファイルを利用できます。ユーザーツールを使って、カスタマイズしたユーザー初期設定ファイルを作成することはできませんが、指定された「スケルトン」ディレクトリにあるユーザー初期設定ファイルでユーザーのホームディレクトリを生成することができます。この作業を行うためには、ユーザーテンプレートツールを使ってユーザーテンプレートを作成したあと、コピーするユーザー初期設定ファイルを保存するスケルトンディレクトリを指定します。
異なるタイプのユーザーにユーザー初期設定ファイルを作成する手順については、「ユーザー初期設定ファイルをカスタマイズする方法」を参照してください。
ユーザーツールで新しいユーザーアカウントを作成して、ホームディレクトリを作成するオプションを選択すると、選択したログインシェルに合わせて次のファイルが作成されます。
表 4–17 ユーザーの追加時にユーザーツールによって作成されるファイル
シェル |
作成されるファイル |
---|---|
C |
/etc/skel/local.cshrc ファイルと /etc/skel/local.login ファイルがユーザーのホームディレクトリにコピーされ、それぞれ、.cshrc と .login という名前に変更されます。 |
Bourne と Korn |
/etc/skel/local.profile ファイルがユーザーのホームディレクトリにコピーされ、.profile という名前に変更されます。 |
Bash シェルをカスタマイズする場合は、ホームディレクトリにある .bashrc ファイルに必要な情報を追加します。Oracle Solaris のインストール時に作成される初期ユーザーは、PATH、MANPATH、およびコマンドプロンプトを設定するための .bashrc ファイルを持っています。詳細については、bash (1) のマニュアルページを参照してください。
ユーザー初期設定ファイルは、管理者とユーザーの両者によってカスタマイズできます。この重要な作業は、「サイト初期設定ファイル」と呼ばれる、大域的に配布されるユーザー初期設定ファイルによって実現します。サイト初期設定ファイルを使用して、ユーザーの作業環境に新しい機能を絶えず導入でき、しかもユーザーはユーザー初期設定ファイルをカスタマイズすることもできます。
ユーザー初期設定ファイルでサイト初期設定ファイルを参照するとき、サイト初期設定ファイルに対して行なったすべての更新は、ユーザーがシステムにログインするときかユーザーが新しいシェルを起動するとき自動的に反映されます。サイト初期設定ファイルは、ユーザーを追加したときにはなかったサイト全体の変更をユーザーの作業環境に配布するよう設計されています。
ユーザー初期設定ファイルでできるカスタマイズは、サイト初期設定ファイルでも行えます。これらのファイルは通常はサーバー、またはサーバーのグループにあり、ユーザー初期設定ファイルの最初の行に現れます。また、各サイト初期設定ファイルは、それを参照するユーザー初期設定ファイルと同じ型のシェルスクリプトでなければなりません。
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 で参照されるディレクトリはすべてユーザーがログインする任意のシステムに自動的にマウントできます。
次の表に、各シェルの基本的な機能を示します。ユーザー初期設定ファイルを作成するときにどのシェルがどのような機能を提供するか参考にしてください。
表 4–18 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 の両シェルでは、任意の大文字の変数名を使って、シェル変数と環境変数の両方を設定できます。また、その後に実行されるコマンドに対して変数を有効にするために、export コマンドを使用します。
すべてのシェルで、シェル変数と環境変数は一般的に大文字の名前で参照します。
ユーザー初期設定ファイルでは、ユーザーのシェル環境を、あらかじめ定義された変数の値を変更するか、変数を追加することによってカスタマイズできます。次の表に、ユーザー初期設定ファイルで環境変数を設定する方法を示します。
表 4–19 ユーザー初期設定ファイルでの環境変数の設定方法
シェルタイプ |
ユーザー初期設定ファイルに追加する行 |
---|---|
setenv MAIL /var/mail/ripley |
|
Bourne または Korn シェル |
VARIABLE=value ; export VARIABLE 例: MAIL=/var/mail/ripley;export MAIL |
次の表では、ユーザー初期設定ファイルでカスタマイズできる環境変数とシェル変数について説明します。各シェルで使用される変数の詳細は、 sh(1)、ksh(1)、csh(1) の各マニュアルページを参照してください。
表 4–20 シェル変数と環境変数の説明
変数 |
説明 |
---|---|
cd コマンドで使用する変数を設定します。cd コマンドの対象ディレクトリを相対パス名で指定すると、cd コマンドは対象ディレクトリをまず現在のディレクトリ (.) 内で検索します。対象ディレクトリが見つからない場合、CDPATH 変数内のパス名のリストが順に検索され、見つかると、ディレクトリの変更が行われます。CDPATH で対象ディレクトリが見つからなかった場合は、現在の作業ディレクトリは変更されません。たとえば、CDPATH 変数が /home/jean に設定されており、/home/jean の下に bin と rje の 2 つのディレクトリがあるとします。/home/jean/bin ディレクトリ内で cd rje と入力した場合、フルパスを指定していなくても、ディレクトリが /home/jean/rje に変更されます。 |
|
C シェルの履歴を設定します。 |
|
ユーザーのホームディレクトリへのパスを設定します。 |
|
ロケールを設定します。 |
|
現在ログインしているユーザーの名前を設定します。LOGNAME のデフォルト値は、passwd ファイルに指定されているユーザー名にログインプログラムによって自動的に設定されます。この変数は参照用にのみ使用し、設定を変更してはいけません。 |
|
ユーザーのデフォルトプリンタを設定します。 |
|
ユーザーのメールボックスへのパスを設定します。 |
|
アクセスできるマニュアルページの階層を設定します。 |
|
ユーザーがコマンドを入力したときに実行するプログラムについて、シェルが検索するディレクトリを順番に指定します。ディレクトリが検索パス上にない場合は、ユーザーはコマンドの絶対パス名を入力しなければなりません。 デフォルトの PATH は、ログインプロセスで .profile (Bourne または Korn シェル) あるいは .cshrc (C シェル) の指定どおりに自動的に定義され、設定されます。 検索パスの順序が重要です。同じコマンドが異なる場所にそれぞれ存在するときは、最初に見つかったコマンドが使用されます。たとえば、PATH が Bourne および Korn シェル構文で PATH=/bin:/usr/bin:/usr/sbin:$HOME/bin のように定義されていて、sample というファイルが /usr/bin と /home/jean/bin の両方にあるものとします。ユーザーが sample コマンドを、その絶対パスを指定しないで入力した場合は、/usr/bin で見つかったバージョンが使用されます。 |
|
C シェルのシェルプロンプトを設定します。 |
|
Bourne または Korn シェルのシェルプロンプトを設定します。 |
|
make、vi、その他のツールが使うデフォルトシェルを設定します。 |
|
代替の terminfo データベースが保存されているディレクトリに名前を付けます。/etc/profile または /etc/.login ファイルで TERMINFO 変数を使用します。詳細は、terminfo(4) のマニュアルページを参照してください。 TERMINFO 環境変数を設定すると、システムはまずユーザーが定義した TERMINFO パスを調べます。ユーザーが定義した TERMINFO ディレクトリ内に端末の定義が見つからなかった場合は、システムはデフォルトディレクトリ /usr/share/lib/terminfo で定義を探します。どちらにも見つからなかった場合、端末は dumb として定義されます。 |
|
端末を設定します。この変数は /etc/profile または /etc/.login ファイルで再設定する必要があります。ユーザーがエディタを起動すると、システムはこの環境変数で定義される名前と同じ名前のファイルを探します。システムは、TERMINFO が参照するディレクトリ内を探して端末の特性を知ります。 |
|
時間帯を設定します。時間帯は、たとえば ls -l コマンドで日付を表示する場合に使われます。TZ をユーザーの環境に設定しないと、システムの設定が使用されます。設定する場合、グリニッジ標準時が使用されます。 |
ユーザーが絶対パス名でコマンドを入力すると、シェルはそのパス名を使ってコマンドを探します。ユーザーがコマンド名しか指定しないと、シェルは 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 です。
次の表に、LANG と LC 環境変数の値の一部を示します。
表 4–21 LANG と LC 変数の値
値 |
ロケール |
---|---|
de_DE.ISO8859-1 |
ドイツ語 |
en_US.UTF-8 |
米国英語 (UTF-8) |
es_ES.ISO8859-1 |
スペイン語 |
fr_FR.ISO8859-1 |
フランス語 |
it_IT.ISO8859-1 |
イタリア語 |
ja_JP.eucJP |
日本語 (EUC) |
ko_KR.EUC |
韓国語 (EUC) |
sv_SE.ISO8859-1 |
スウェーデン語 |
zh_CN.EUC |
簡体字中国語 (EUC) |
zh_TW.EUC |
繁体字中国語 (EUC) |
サポートされるロケールの詳細については、『国際化対応言語環境の利用ガイド』を参照してください。
次の例は、LANG 環境変数を使ってロケールを設定する方法を示しています。C シェルユーザー初期設定ファイルでは、次の行を追加してください。
setenv LANG de_DE.ISO8859-1 |
Bourne シェルまたは Korn シェルユーザー初期設定ファイルでは、次の行を追加してください。
LANG=de_DE.ISO8859-1; export LANG |
ファイルまたはディレクトリを作成したときに設定されるデフォルトのファイルアクセス権は、「ユーザーマスク」によって制御されます。ユーザーマスクは、初期設定ファイルで umask コマンドによって設定されます。現在のユーザーマスクの値は、umask と入力して Return キーを押すと表示できます。
ユーザーマスクは、次の 8 進値で構成されます。
最初の桁でそのユーザーのアクセス権を設定する
2 桁目でグループのアクセス権を設定する
3 桁目でその他 (「ワールド」とも呼ばれる) のアクセス権を設定する
最初の桁がゼロの場合、その桁は表示されません。たとえば、ユーザーマスクを 022 に設定すると、22 が表示されます。
設定する umask の値は、与えたいアクセス権の値を 666 (ファイルの場合) または 777 (ディレクトリの場合) から引きます。引いた残りが umask に使用する値です。たとえば、ファイルのデフォルトモードを 644 (rw-r--r--) に変更するとします。このとき 666 と 644 の差 022 が umask コマンドの引数として使用する値です。
また、次の表から umask 値を決めることもできます。この表は、umask の各 8 進値から作成される、ファイルとディレクトリのアクセス権を示しています。
表 4–22 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 |
ここでは、ユーザー自身の初期設定ファイルのカスタマイズを始める際に使用するユーザー初期設定ファイルとサイト初期設定ファイルの例を示します。例の中のシステム名やパス名は、実際のサイトに合わせて置き換えてください。
(Line 1) PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:. (Line 2) MAIL=/var/mail/$LOGNAME (Line 3) NNTPSERVER=server1 (Line 4) MANPATH=/usr/share/man:/usr/local/man (Line 5) PRINTER=printer1 (Line 6) umask 022 (Line 7) export PATH MAIL NNTPSERVER MANPATH PRINTER |
ユーザーのシェル検索パスを設定する
ユーザーのメールファイルへの検索パスを設定する
ユーザーの Usenet ニュースサーバーを設定する
マニュアルページへのユーザーの検索パスを設定する
ユーザーのデフォルトプリンタを設定する
ユーザーのデフォルトのファイル作成アクセス権を設定する
指定された環境変数をエクスポートする
(Line 1) set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin) (Line 2) setenv MAIL /var/mail/$LOGNAME (Line 3) setenv NNTPSERVER server1 (Line 4) setenv PRINTER printer1 (Line 5) alias h history (Line 6) umask 022 (Line 7) source /net/server2/site-init-files/site.login |
ユーザーのシェル検索パスを設定する
ユーザーのメールファイルへの検索パスを設定する
ユーザーの 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 という名前のサーバー上にあります。また、自動マウンタがユーザーのシステムで実行されていることを前提としています。