第 25 章 BSM サービスの管理 (手順)

この章では、監査を組み込んだ Solaris 環境を設定および管理する手順について説明します。また、監査トレールおよびデバイス割り当ての管理方法についても説明します。この章では、次の内容について説明します。

• BSM の管理 (作業マップ)

• 監査ファイルの構成 (作業マップ)

• 監査サービスの構成 (作業マップ)

• 監査レコードの管理 (作業マップ)

• 割り当て可能デバイスの追加 (作業マップ)

BSM の管理 (作業マップ)

次の作業マップは、BSM サービスの管理に必要な主な作業の一覧です。

監査ファイルの構成

ネットワーク上で監査プロセスを有効にする前に、監査構成ファイルを編集します。このあとに説明する手順の多くは、サービスの再開またはローカルシステムのリブートが必要です。監査構成ファイルの編集は、できるだけ BSM サービスを開始する前に完了してください。

監査ファイルの構成 (作業マップ)

次の表は、この節で説明する操作の一覧です。

監査フラグの変更方法

監査フラグは、/etc/security/audit_control ファイルに定義されます。監査フラグを使用して、監査ログに記録する監査レコードのクラスを選択します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_control ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_control /etc/security/audit_control.save

3. audit_control ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   title:string

   title	行の種類を定義する。dir:、flags:、minfree:、または naflags:を選択できる
   string	この種類の行に関連付けるデータを指定する

4. 監査デーモンを実行して、新しい audit_control ファイルを読み込みます。

   監査デーモンの内部に、読み込んだ情報が格納されます。新しい情報を使用するには、システムをリブートするか、次のコマンドを入力します。

   # audit -s

例—監査トレールファイルの位置を変更する

dir: で始まる行には、監査トレールファイルの格納に使用する監査ファイルシステムを定義します。この例では、監査トレールファイルの位置を 2 つ追加定義しています。

# cat /etc/security/audit_control
dir:/etc/security/audit/host.1/files
dir:/etc/security/audit/host.2/files
dir:/var/audit
flags:
minfree:10
naflags:lo

例 — すべてのユーザーに適用される監査フラグを変更する

audit_control ファイルの flags 行には、監査するイベントのクラスを定義します。このフラグは、ホスト上のすべてのユーザーに適用されます。クラスは空白を入れずにコンマで区切ります。この例では、すべてのユーザーを対象に lo クラスのイベントが監査されます。

# cat /etc/security/audit_control
dir:/var/audit
flags:lo
minfree:10
naflags:lo

例 — 警告に対するソフト制限値を変更する

audit_control ファイルの minfree 行には、すべての監査ファイルシステムの最小空き領域レベルを定義します。この例では、利用できるファイルシステムの領域が 10 % だけになったときに警告が発行されるように、ソフト制限値を設定しています。

# cat /etc/security/audit_control
dir:/var/audit
flags:
minfree:10
naflags:lo

例 — ユーザーに起因しないイベントの監査を変更する

audit_control ファイルの naflags: 行には、ホスト上のすべてのユーザーを対象に監査する、ユーザーに起因しないイベントのクラスを定義します。クラスは空白を入れずにコンマで区切ります。この例では、na イベントクラスが追加されます。

# cat /etc/security/audit_control
dir:/var/audit
flags:
minfree:10
naflags:lo,na

ユーザーの監査特性の変更方法

ユーザーごとの定義は、/etc/security/audit_user ファイルに格納できます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_user ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_user /etc/security/audit_user.save

3. audit_user ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   username:always:never
   

   username	監査するユーザー名を選択する
   always	常に監査する監査クラスの一覧を選択する
   never	監査しない監査クラスの一覧を選択する

   複数のフラグを指定するには、監査クラスをコンマで区切ります。監査ファイルの詳細は、監査フラグ を参照してください。

4. BSM サービスで新しいデータを有効にします。

   新しいデータを使用するには、システムをリブートするか、いったんログアウトしてからログインし直します。

例 — 1 人のユーザーの監査を変更する

この例のエントリでは、ユーザー sue がログインクラス (lo) の任意のプログラムにアクセスすると、監査レコードが生成されます。

# grep sue /etc/security/audit_user
sue:lo:

例 — 監査管理ログインを作成する

監査パーティションがすべていっぱいの場合は、ホストにログインできなくなります。すべてのログインを監査している場合は、監査パーティションがいっぱいになると、すべてのユーザーがログインを完了できなくなります。この状況を回避するために、監査を行わない特別なログインを設定できます。この新しいログインを使用すると、監査パーティションがいっぱいの場合でも、ホストにログインできます。また、このログインを使用して、いっぱいになったパーティションの問題を修復できます。この例では、ユーザー auditadm を監査しないように定義します。

# grep auditadm /etc/security/audit_user
auditadmin:no:yes

監査管理ログインとして機能するユーザーログインは、ほかの方法で監視する必要があります。

監査クラスの変更方法

監査クラスは、/etc/security/audit_class ファイルに定義されます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_class ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_class /etc/security/audit_class.save

3. audit_class ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   0xnumber:name:description

   number	一意の監査クラスマスクを定義する
   name	監査クラスの 2 文字の名前を定義する
   description	監査クラスの記述名を定義する

4. BSM サービスで新しいデータを有効にします。

   新しいデータを使用するには、システムをリブートするか、次のコマンドを入力します。

   # auditconfig -conf

例 — 新しい監査クラスを設定する

手順 3 で、次のようなエントリを追加して、de という新しい監査クラスを設定します。

0x00010000:de:device allocation

監査イベントの変更方法

監査イベントの定義は、/etc/security/audit_event ファイルに格納されます。レコードの生成は、イベント定義が作成され、ユーザーレベルの動作によってイベントが生成されたときにだけ行われます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_event ファイルのバックアップコピーを保存します。

   # cp /etc/security/audit_event /etc/security/audit_event.save

3. audit_event ファイルに新しいエントリを追加します。

   各エントリの書式は次のとおりです。

   number:name:description:classes
   

   number	一意の監査イベント番号を定義する。32768 以降の番号を指定する
   name	一意の監査イベント名を定義する
   description	監査イベントの説明を記述する。監査イベントのマニュアルページ名が含まれることが多い
   classes	このイベントを含む監査クラスを選択する

4. BSM サービスで新しいデータを有効にします。

   新しいデータを使用するには、システムをリブートするか、次のコマンドを入力します。

   # auditconfig -conf

例 — 新しい監査イベントを追加する

この例のエントリでは、ローカルアプリケーションの新しい監査イベントを定義します。

# grep localapp /etc/security/audit_event
32769:aue_localapp:localapp(1):ap

監査サービスの構成

この節では、監査サービスを構成して有効にするために必要な作業について説明します。

監査サービスの構成 (作業マップ)

次の表は、監査の構成に必要な操作の一覧です。

監査パーティションの作成方法

次の手順では、監査用のパーティションの作成方法、および監査に対応するファイルシステムとディレクトリの作成方法について説明します。すでに空のパーティションがある場合、またはすでに空のファイルシステムをマウントしている場合は、必要に応じて手順を省略してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. 必要なディスク容量を決定します。

   ホストごとに 200M バイト以上を割り当てます。ただし、ディスク容量の要件は、実行する監査のボリュームによって異なります。つまり、ディスク容量の要件が割り当てる数値を超えることがあります。予備ディレクトリのパーティション領域も含めてください。

3. 必要に応じて、監査パーティションを作成します。

   この手順は、サーバーのインストール時に実行するのが最も簡単です。サーバーにマウントされていないディスク上にパーティションを作成することもできます。パーティション作成方法の詳細については、『Solaris のシステム管理 (基本編)』の「UFS ファイルシステムの作成」を参照してください。

   # newfs /dev/rdsk/cwtxdysz

   /dev/rdsk/cwtxdysz は、パーティションの raw デバイス名です。

   ローカルホストを監査する場合は、予備の監査ディレクトリも作成します。

4. 新しいパーティションのマウント先を作成します。

   # mkdir /var/audit/server-name.n

   server-name.n は、サーバー名と、各パーティションの識別番号です。この識別番号は省略できますが、多数の監査ディレクトリを作成する場合はこの番号を使用すると便利です。

5. 新しいパーティションを自動的にマウントするエントリを追加します。

   /etc/vfstab ファイルに次のような行を追加します。

   /dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n ufs 2 yes

6. (省略可能) 各パーティションの最小空き容量のしきい値を削除します。

   デフォルトの構成を使用した場合、ディレクトリの 80% がいっぱいになったときに警告が生成されます。このため、パーティション上に空き容量を予約する必要はありません。

   # tunefs -m 0 /var/audit/server-name.n

7. 新しい監査パーティションをマウントします。

   # mount /var/audit/server-name.n

8. 新しいパーティションに監査ディレクトリを作成します。

   # mkdir /var/audit/server-name.n/files

9. マウント先と新しいディレクトリへのアクセス権を訂正します。

   # chmod -R 750 /var/audit/server-name.n/files

10. (省略可能) ファイルサーバー上で、ほかのホストからアクセスできるファイルシステムを定義します。

    通常は、監査レコードを格納するために、ディスクファームをインストールします。監査ディレクトリを複数のシステムで使用する場合は、そのディレクトリを NFS サービスを通して共有する必要があります。/etc/dfs/dfstab ファイルに対して、次のようなエントリをディレクトリごとに追加します。

    share -F nfs /var/audit/server-name.n/files

11. (省略可能) ファイルサーバー上で、NFS サービスを起動し直します。

    share コマンドまたは share コマンドセットを初めて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドでデーモンを終了し、再起動してください。NFS サービスの詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「NFS サービスの設定」 を参照してください。

    # /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start

例 — 予備の監査ディレクトリを作成する

監査サービスを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが egret という名前のシステムに追加されます。このファイルシステムは、ローカルシステムだけで使用されるため、続いてファイルサーバーの手順は必要ありません。

# newfs /dev/rdsk/c0t2d0
# mkdir /var/audit/egret
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret ufs  2  yes  -
# tunefs -m 0 /var/audit/egret
# mount /var/audit/egret
# mkdir /var/audit/egret/files
# chmod -R 750 /var/audit/egret/files

例 — 新しい監査パーティションを作成する

この例では、新しいファイルシステムが、2 つの新しいディスクに作成されます。この 2 つのディスクは、ネットワーク上のほかのシステムと共有します。

# newfs /dev/rdsk/c0t2d0
# newfs /dev/rdsk/c0t2d1
# mkdir /var/audit/egret.1
# mkdir /var/audit/egret.2
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret.1 ufs  2  yes  -
/dev/dsk/c0t2d1s1  /dev/rdsk/c0t2d1s1  /var/audit/egret.2 ufs  2  yes  -
# tunefs -m 0 /var/audit/egret.1
# tunefs -m 0 /var/audit/egret.2
# mount /var/audit/egret.1
# mount /var/audit/egret.2
# mkdir /var/audit/egret.1/files
# mkdir /var/audit/egret.2/files
# chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files
# grep egret /etc/dfs/dfstab
 share -F nfs /var/audit/egret.1/files
 share -F nfs /var/audit/egret.2/files
# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

audit_warn 別名の構成方法

audit_warn スクリプトは、audit_warn という別名に対してメールを生成します。このメールを有効な電子メールアドレスに送信するには、次のいずれかの手順を行います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) audit_warn 別名を他の別名と交換します。

   たとえば、audit_warn スクリプトを編集して、audit_warn をほかの別名に置き換えます。 audit_warn を root と交換すると、電子メールメッセージを送信する行は次のようになります。

   /usr/ucb/mail -s "$SUBJECT" root

   スクリプト内の 10 行にこの変更を適用する必要があります。

3. (省略可能) audit_warn の電子メールをほかの別名にリダイレクトします。

   また、/etc/mail/aliases ファイル内の電子メールをリダイレクトしても指定できます。この場合、次のような別名をローカルの /etc/mail/aliases ファイルか、名前空間の mail_aliases データベースに追加します。電子メールを root 別名に送信する場合、新しいエントリは次のようになります。

   audit_warn: root

監査ポリシーを有効または無効にする方法

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査ポリシーでは、特定の構成を有効または無効にします。デフォルトでは、すべての監査ポリシーが無効になっています。使用する監査ポリシーは、有効にする必要があります。各ポリシーについては、監査ポリシーを参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. (省略可能) 既存の監査ポリシーを確認します。

   監査ポリシーを変更するときは、現在使用されているポリシーをすべて確認してください。次のコマンドを実行すると、有効なポリシーがすべて表示されます。

   # auditconfig -lspolicy

3. 監査ポリシーを有効または無効にします。

   # auditconfig -setpolicy flagpolicyname

   flag	+ を指定すると、ポリシーが有効になる。– を指定すると、ポリシーが無効になる
   policyname	有効または無効にするポリシーを選択する

   このポリシーは、次回ブートしたとき、または auditconfig -setpolicy コマンドを使ってポリシーを変更したときに有効になります。

例 — cnt ポリシーを設定する

cnt ポリシーを設定すると、監査パーティションがいっぱいになっても、プロセスはブロックされません。パーティションがいっぱいになると、レコードは破棄されます。ただし、監査プロセスがイベントを記録していない場合でも、システムは引き続き動作します。セキュリティを重視する場合は、cnt ポリシーは設定しないでください。ファイルシステムがいっぱいになると、イベントが記録されないことがあるためです。

次のコマンドを実行すると、cnt ポリシーが有効になります。

# auditconfig -setpolicy +cnt

サイトのセキュリティを確保するには、適切な起動ファイルの cnt ポリシーを有効にする必要があります。

監査を有効にする方法

この操作では、監査サービスが開始されます。監査サービスが構成されている場合は、ホストをリブートしたときにもサービスが開始します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. システムをシングルユーザーモードにします。

   # /etc/telinit 1

   詳細は、telinit(1M) のマニュアルページを参照してください。

3. スクリプトを実行して、システムが監査を実行するように構成します。

   /etc/security ディレクトリに移動し、bsmconv スクリプトを実行します。このスクリプトによって、リブート後に標準 Solaris マシンが設定され、BSM が実行されます。bsmconv(1M) のマニュアルページを参照してください。

   # cd /etc/security # ./bsmconv

4. システムをマルチユーザーモードにします。

   # /etc/telinit 6

   システムがマルチユーザーモードに移行すると、起動ファイル /etc/security/audit_startup によって監査デーモンが自動的に動作します。

   ---

   注 –

   bsmconv スクリプトを実行すると、Stop-A によるシステムの強制終了機能を無効にする行が追加されます。Stop-A によるシステムの強制終了機能を保持するには、/etc/system ファイルの set abort_enable=0 という行をコメントアウトする必要があります。

   ---

監査を無効にする方法

BSM が不要になった場合は、bsmunconv コマンドを実行して無効にすることができます。bsmconv(1M) のマニュアルページを参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. システムをシングルユーザーモードにします。

   # /etc/telinit 1

   詳細は、telinit(1M) のマニュアルページを参照してください。

3. スクリプトを実行して、監査を無効にします。

   /etc/security ディレクトリに移動し、bsmunconv スクリプトを実行します。

   # cd /etc/security # ./bsmunconv

4. システムをマルチユーザーモードにします。

   # /etc/telinit 6

   ---

   注 –

   bsmunconv スクリプトを実行すると、Stop-A によるシステムの強制終了機能を無効にする行が削除されます。bsmunconv スクリプトを実行したあとで、ユーザーが Stop-A を使用してもシステムが強制終了しないようにする場合は、/etc/system ファイルに set abort_enable=0 という行を入力し直す必要があります。

   ---

監査レコードの管理

監査トレールを管理することによって、ネットワーク上のユーザーの動作を監視することができます。監査プロセスを行うと、大量のデータが生成される可能性があります。次の手順では、さまざまな監査データを使用して作業を行う方法について説明します。

監査レコードの管理 (作業マップ)

次の表は、この節で説明する操作の一覧です。

監査レコードのマージ方法

次のタスクでは、すべての監査ディレクトリのすべての監査ファイルをマージする方法について説明します。監査トレールの内容を分析する場合は、次の手順を行います。

1. スーパーユーザー、またはそれと同等の役割になります。

2. 一次監査ディレクトリに移動します。

   # cd /etc/security/audit/server-name.1/files

   このディレクトリに移動すると、マージしたファイルがこの保護されたディレクトリに配置されます。

3. 監査レコードをマージします。

   # auditreduce> merged.log

   server-name 上の audit_control ファイルの dir: 行に指定されているすべてのディレクトリがマージされ、merged.log というファイルに格納されます。

例 — 監査トレール全体を表示する

監査トレール全体を一度に表示するには、auditreduce コマンドの出力を praudit コマンドにパイプします。

# auditreduce | praudit

例 — 監査トレール全体を印刷する

出力を lp コマンドにパイプすると、その出力はプリンタに送られます。

# auditreduce | praudit | lp

例 — 監査ファイルの結合と削減

auditreduce の -O オプションを使用して、複数の監査ファイルを 1 つのファイルに結合し、そのファイルを指定した出力ファイルに保存します。auditreduce を使用すると、監査ファイルの結合と削除を自動的に実行できます (auditreduce(1M) のマニュアルページの -C と -D オプションを参照)。ただし、多くの場合、 find コマンドなどを使用して手動でファイルを選択し、auditreduce を使用してファイル名を指定する方が簡単です。

この方法で auditreduce を使用すると、入力ファイルのすべてのレコードが 1 つの出力ファイルにマージされます。マージが完了したら、入力ファイルは削除する必要があります。また、出力ファイルは、/etc/security/audit/server-name /files という名前のディレクトリに保存し、auditreduce が出力ファイルを検索できるようにする必要があります。

# auditreduce -O combined-filename

auditreduce コマンドを使用すると、入力ファイルを結合するときに不要なレコードを除外して、出力ファイル内のレコード数を削減することもできます。たとえば、auditreduce を使用して、監査ファイルから 1 か月以上経過した記録のログインレコードとログアウトレコードだけを保持して、ほかのすべてのレコードを削除することができます。監査トレール全体が必要になった場合は、バックアップテープから復元することができます。

# auditreduce -O daily.summary -b 19990413 -c lo; compress *daily.summary
# mv *daily.summary /etc/security/summary.dir

例 — 選択した日付のユーザーの動作を表示する

次の例では、システム管理者が lo イベントクラスを要求して、ユーザー tamiko が 1999 年 4 月 13 日にログインしてログアウトした時刻を調べます。短い書式の日付は、yymmdd 形式で出力されます。長い書式については、auditreduce(1M) のマニュアルページを参照してください。

# auditreduce -d 990413 -u tamiko -c lo | praudit

例 — 選択レコードを 1 つのファイルにコピーする

この例では、特定の日付のログインおよびログアウトメッセージが監査トレールから選択され、対象ファイルにマージされます。対象ファイルは、通常の監査ルートディレクトリ以外のディレクトリに書き込まれます。

# auditreduce -c lo -d 990413 -O /usr/audit_summary/logins 

-O オプションを使用すると、開始時刻と終了時刻を示す 14 文字のタイムスタンプと接尾辞 logins が付いた監査ファイルが作成されます。

/usr/audit_summary/19990413000000.19990413235959.logins

例 — not_terminated 監査ファイルを整理する

監査ファイルが開いているときに監査デーモンが終了したり、サーバーがアクセス不能になって新しいサーバーに切り替わったりすることがあります。このような場合、その監査ファイルは監査レコードとして使用されなくなりますが、監査ファイルの終了時刻として文字列 not_terminated が付いたままになります。このようなファイルが検出された場合は、ファイルが使用されていないことを手動で検証し、正しいオプションを使用してファイル名を指定して整理します。

# audit -s
19990414121112.not_terminated.egret
# auditreduce -O egret 19990413120429.not_terminated.egret

audit コマンドは、現在の監査ファイル名を確認します。auditreduce コマンドは、正しい名前、正しいタイムスタンプ、および正しい接尾辞 (egret) を使用して新しい監査ファイルを作成し、すべてのレコードをそのファイルにコピーします。

監査レコードの書式の表示方法

次のコマンドは、すべての監査イベントレコードの書式を表示します。このコマンドは、audit_class、 audit_event、および audit_record_attr ファイルのレコードを操作します。

# bsmrecord -a

例 — 監査レコードの書式を表示する

この例では、ID 6152 の監査レコードの書式を表示します。

# bsmrecord -i 6152
# login: terminal login
program  /usr/sbin/login  see login(1)
event ID 6152             AUE_login
class  lo  (0x00001000)
header-token
subject-token
text-token   error message
exit-token
#

監査トレールのオーバーフローを防ぐ方法

セキュリティポリシーの関係ですべての監査データを保存する必要がある場合は、次の手順に従います。

1. 定期的に監査ファイルを保存し、保存した監査ファイルを監査ファイルシステムから削除するスケジュールを設定します。

2. バックアップをテープに作成するか、保存ファイルシステムに移動して、監査ファイルを手動で保存します。

3. 監査レコードの解釈に必要な、内容に対応する情報を、監査トレールとともに格納します。

4. オフラインで移動した監査ファイルをを示すレコードを保管します。

5. 保存したテープを適切な方法で保管します。

6. サマリーファイルを作成して、格納する監査データのボリュームを削減します。

   auditreduce でオプションを使用すると、監査トレールからサマリーファイルを抽出できるため、サマリーファイルには指定した種類の監査イベントのレコードだけが含まれます。この例については、例 — 監査ファイルの結合と削減 と 例 — 選択レコードを 1 つのファイルにコピーする を参照してください。

デバイス割り当ての管理

デバイス割り当てを使用して、さまざまなリムーバブルメディアに関連するセキュリティリスクを減らすことができます。

割り当て可能デバイスの追加 (作業マップ)

次の表は、新しい割り当て可能デバイスの定義に必要な、主な手順の一覧です。

割り当て可能デバイスのロックファイルの設定方法

ロックファイルとは、 /etc/security/dev ディレクトリに作成されるサイズ 0 のファイルです。割り当て可能デバイスごとに 1 つのファイルが作成されます。割り当て可能デバイスのロックファイルがない場合は、そのデバイスを割り当てることができず、誰もアクセスできません。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. dminfo コマンドを使用して、 device_maps ファイルのエントリからそのデバイスのデバイス名を取得します。

   device_maps ファイル と、dminfo(1M) および device_maps(4) のマニュアルページを参照してください。たとえば、デバイスタイプ st のデバイス名は st0 です。次の手順では、そのデバイス名をロックファイル名として使用します。

3. touch コマンドを使用して、そのデバイスの空のロックファイルを作成します。

   ファイル名としてデバイス名を使用します。device-name に代入してください。

   # cd /etc/security/dev # touch device-name # chmod 600 device-name # chown bin device-name # chgrp bin device-name

割り当て可能デバイスの変更方法

次の手順では、デバイス割り当てメカニズムに使用できるデバイスを定義します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. /etc/security/device_allocate ファイルに一覧されているデバイスを確認します。

3. device_allocate ファイルには指定されていないデバイスのうち、割り当て可能にするデバイスを決定します。

4. device_allocate ファイルを編集して新しいデバイスを追加します。

   各エントリの書式は次のとおりです。

   device-name;device-type;;;;program

   device-name	デバイス名を指定する
   device-type	デバイスタイプを指定する
   program	実行するパージプログラムを指定する

デバイスを割り当てる方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. デバイス名を指定して allocate コマンドを使用します。

sar1% allocate st0

allocate コマンドの - g オプションを使用して、デバイスタイプでデバイスを割り当てることもできます。

コマンドでデバイスを割り当てられない場合は、コンソールウィンドウにエラーメッセージが表示されます。割り当てのエラーメッセージについては、allocate(1) のマニュアルページを参照してください。

例 — プリンタを割り当てる

sarl% allocate /dev/lp/chestnut

allocate コマンドを実行したユーザーだけがプリンタを使用できます。

デバイスの割り当てを解除する方法

deallocate コマンドに続けてデバイスファイル名を使用し、デバイスの割り当てを解除します。

sar1% deallocate st0

割り当てを解除すると、ほかのユーザーもユーザーの使用後にそのデバイスを割り当てて使用できるようになります。

例 — プリンタの割り当てを解除する

chestnut という名前のプリンタの割り当てを解除するには、次のコマンドを入力します。

# deallocate /dev/lp/chestnut

例 — 強制的に割り当てを解除する

ユーザーに割り当てられたデバイスは、プロセスが終了するとき、またはそのユーザーがログアウトするときに、自動的にその割り当てが解除されます。次の書式の deallocate コマンドは、通常、ユーザーが特定のデバイスの割り当てを解除し忘れなかったときに使用します。割り当てが強制的に解除され、ほかのユーザーはそのデバイスを割り当てることができます。

# deallocate -F st0

例 — すべてのデバイスの割り当てを解除する

すべてのデバイスの割り当てを解除できるのは、システムを初期化しているときだけです。

# deallocate -I