test

Trusted Solaris 管理の手順

第 4 章 役割の管理

この章では、役割の作成と変更に関する前提知識と、実際の操作方法を紹介します。この章には次の項目があります。

この章では次の操作手続きを示します。

役割アカウントとユーザーアカウントの違い

役割アカウントはユーザーアカウントの特性をすべて保持していますが、以下の点が異なっています。

管理役割と非管理役割の違い

役割には次の 2 つの種類があります。

非管理役割

オペレータ (oper) はデフォルトのシステムでは、次の非管理役割だけが存在します。

オペレータ役割はバックアップ作業とプリンタ管理を行うための役割です。オペレータ役割の行う機能は、トラステッドパス属性をはじめ、「管理役割」に述べる「管理役割」の持ついかなる特性も必要としません。

非管理役割を作成する場合

非管理役割は、複数ユーザーに同じプロファイルを割り当てる上で、次のような利点を持っています。

たとえば、複数のユーザーを help というサポート役割になるように設定します。この場合、help 役割から出されるメールはすべて単一の名前で出されます。したがって、help 役割内で作業しているユーザーはカスタマからは識別できません。

管理役割

デフォルトの Trusted Solaris システムでは、次の 2 つの主要な管理役割があります。

上記以外に、第 3 の任意の管理役割として、root 役割が存在します。root 役割は、ソフトウェアのインストールのように番号 0 の実 UID (root の UID) を必要とする作業を行うものです。root 役割は、通常、セキュリティ管理役割を持つアカウントに割り当てられます。これは、root の機能が制限されている一方で root 役割の主な機能であるソフトウェアの追加は、セキュリティに直接かかわってくるからです

管理役割には次のような特徴があります。

新しい管理役割を作成する場合

各サイトでは、トラステッドパス属性を検査するようなコマンドやアクションを使用する役割が必要となった場合、新しい管理役割を作成できます。たとえば、3 つのデフォルトの管理役割を 1 つの役割にまとめたい場合、そのような機能を持つ新しい管理的役割を作成できます。詳しくは 「2 つの役割による分割管理を取らない場合」 を参照してください。

トラステッドパス属性

トラステッドパス属性は、ブート時、あるいはプログラムが管理役割ワークスペースで動作しているときに取得できます。プログラムがトラステッドパス属性を取得できるのは、そのプログラムがブートプロファイルまたは管理役割に割り当てられているプロファイルに指定されているときだけです。

多くの管理コマンドやアクションにはトラステッドパス属性が必要です。たとえば、プロファイルシェルが管理役割の代わりに起動されるとき (たとえば、デフォルトのプロファイルシェルで端末エミュレータを起動するときや、(管理) 役割がプロファイルシェルのスクリプトを実行するとき)、プロファイルシェルはトラステッドパス属性を検査します。管理役割ワークスペースにウィンドウを作成するコマンドやスクリプト (多くのインストールスクリプトなど) にはトラステッドパス属性が必要です。次の表に、これ以外のコマンドやツールの一覧を示します。

表 4-1 トラステッドパスを必要とするコマンド、オプションおよびアプリケーション
 コマンドまたはアプリケーション オプション

audit(1M)

 

auditd(1M)

 
login(1)-d および -f
lpsched(1M) 
runpd(1M) 
sendmail(1M)-ba, -bd, -bi, -bs, -bt, -bv, -M, -X, -d, -q
 Database Manager (dbmgr) 
 Group Manager (groupmgr) 
 Host Manager (hostmgr) 
 Printer Manager (printermgr) 
 Profile Manager (profilemgr) 
 Serial Manager (serialmgr) 
 User Manager (usermgr) 

トラステッドパスの警告

デフォルトのシステムでは、作業しやすくなるように、管理役割には All Commands プロファイルが割り当てられています。All Commands プロファイルが割り当てられた役割は、特権または他の拡張セキュリティ属性なしにコマンドを実行できます。あるプログラム (コマンド) が役割のプロファイルの 1 つに明示的に指定されていないとき、プロファイルシェルは常にトラステッドパス属性を無効にし、(そのプログラムが起動されると)、次のようなメッセージを表示します。

WARNING: Command operating outside of the Trusted Path!

このメッセージは、実行しようとしているコマンドにセキュリティ制限を回避する権利が与えられていないことを役割に知らせます。コマンドが成功したとしても、警告は表示されます。エラー警告を抑制するには、-Q オプションを使います。つまり、管理役割はプロファイルシェルのコマンド行で set -Q と入力するか、$HOME/.profile ファイルに set -Q を入力します。

プログラムが失敗したとき、プログラムにトラステッドパス属性が欠如していることを示す警告が表示されます。このエラーは、インストールプログラムが管理役割ワークスペースでウィンドウを起動しようとして失敗したときに表示されます。また、トラステッドパス属性を持たない管理役割はプロファイルシェルを起動できないため、シェルスクリプトがプロファイルシェルを使ったときにもこのエラーが表示されます。どちらの場合でも、修正するには、役割に割り当てられているプロファイルにインストールプログラムまたはシェルスクリプトを追加します。

ほとんどの管理作業で使われる Solstice AdminSuite ツールはトラステッドパス属性を検査します。したがって、表 4-1 の一覧にあるプログラムやオプションなどにアクセスする必要がある新しい役割をセキュリティ管理者が作成する場合、セキュリティ管理者役割は新しい役割を管理役割として指定する必要があります。

ユーザーアカウントおよび管理アカウントを管理する作業の分割

次の図で説明するように、デフォルトの Trusted Solaris システムでは、管理者役割とセキュリティ管理者役割は、一連のユーザーアカウントの規定された特性をそれぞれ設定します。図 4-1 に示すように、セキュリティ管理者は、一般ユーザー アカウントおよびすべての役割アカウントの持つ特性のうち、セキュリティ関連のものの設定を受け持ちます。一方、管理者は、一般ユーザーアカウントの特性の設定と同時に、セキュリティ管理者の特性の設定を受け持ちます。これは、いかなる役割も自分自身を設定することはできないためです。

図 4-1 アカウントやプロファイル設定に関してセキュリティ管理者と管理者役割間で行われる責任の分担

Graphic

アカウント管理作業を使用するための承認

図 4-2 に、ユーザーアカウントや役割アカウントの追加に使用するユーザーマネージャの「ナビゲータ (追加)」メニューを示します。「コメント (Comment)」の下には 8 つのボタンがあり、各ボタンには、アカウントごとに指定する情報の種類を示すラベルが付けられています。各ボタンを押すと、それぞれに対応するダイアログボックスが表示され、そこで指定の情報を入力できます。これらのボタンは、ユーザーマネージャの「ナビゲータ」ダイアログボックスを使って、ユーザーアカウントの追加または変更を行う場合にのみ表示されます。

図 4-2 ユーザーマネージャの「ナビゲータ」ダイアログボックス

Graphic

どちらのボタンにも承認が必要です。デフォルトでは、これらの承認はセキュリティ管理者役割と管理者役割に分割され、アカウント管理を 2 人で保守するように構成されています。

注 -

管理役割がユーザーマネージャを起動した時に、これらのボタンのうちのどれかがグレー表示されていた場合、そのボタンを使用するのに必要となる承認が、現在の役割の持つ実行プロファイルに割り当てられていないことを意味します。

各ボタンの使用に必要となる承認と、各ボタンに対応するダイアログボックスをまとめたものを表 4-2 に示します。詳細は、auth_desc(4) のマニュアルページを参照してください。

表 4-2 各種ユーザー情報の指定に必要となる承認
 ユーザーマネージャのボタン 承認名 承認番号 承認の内容
 識別情報 (Identity)ユーザーの識別情報を設定 (set user identity)17 ユーザーの持つ ID に関するセキュリティ情報 (ユーザー名、主グループ、補助グループ、コメント、ログイン) を、ユーザーマネージャを使用して管理者が設定できるようにする。ユーザーの追加、コピー、削除に必要となる。
 パスワード (Password) ユーザーのパスワードを設定 (set user password)18 ユーザーの持つパスワード関連の情報 (パスワード、パスワードの種類、有効期間、有効期限、警告の表示、資格テーブル設定の許可) を、ユーザーマネージャを使用して管理者が設定できるようにする。
 ホーム (Home)ホームディレクトリの属性を設定 (set home directory attributes)25 ユーザーのホームディレクトリに関する事項(場所、アクセス権、初期内容)を、ユーザーマネージャを使用して管理者が設定できるようにする。
 ラベル (Labels)ユーザーのラベルを設定 (set user labels)20 ユーザーに割り当てられている各種ラベル関連の情報 (ユーザーの最下位ログインラベル、認可上限、ラベル表示、ラベル変換属性) を、ユーザーマネージャを使用して管理者が設定できるようにする。
 プロファイル (Profiles)ユーザーのプロファイルを設定 (set user profiles)22 ユーザーへのプロファイルの割り当てを、ユーザーマネージャを使用して管理者が設定できるようにする。
 役割 (Roles)役割リストを設定 (set roles list)24 ユーザーがなることができる役割を、ユーザーマネージャを使用して管理者が選択できるようにする。
 アイドル (Idle)アイドル時間を設定 (set idle time)23 アイドル時間の設定、およびワークステーションが指定の期間アイドル状態となった場合に実行するコマンドを、ユーザーマネージャを使用して管理者が設定できるようにする。

注 -

上の表に示したデフォルトの承認を使うと、特定の役割が、自分自身を除く、他のすべてのユーザーアカウントおよび役割アカウントの情報を変更できます。たとえば、「ユーザーのパスワードを設定」承認を使うことにより、セキュリティ管理者は、自分自身を除く他のすべてのアカウントのパスワードのオプションを設定できます。

自分自身の役割に関する情報を指定するための承認

「自分を変更することを許可」承認を特定の役割に与えると、その役割は自分自身の役割アカウントの承認情報を指定できるようになります。デフォルトでは、どちらの管理役割のプロファイルもこの承認を持ちません。

「自分を変更することを許可」承認を持つ役割は、自分自身のために、すでに必要な承認を持っている属性だけを構成できます。たとえば、管理者役割が「自分を変更することを許可」特権をセキュリティ管理者役割に割り当てられている実行プロファイルに追加した場合、セキュリティ管理者役割は自分のアカウントのセキュリティ関連の事項だけを指定でき、その役割に承認されていない事項 (「識別 (Identify)」ダイアログボックスの設定など) は指定できません。

注 -

「自分を変更することを許可」承認を許可しても、役割がその役割アカウント自身に割り当てられたプロファイルを編集することはできません。

2 つの役割による分割管理を取らない場合

サイトのセキュリティポリシーが許すならば、セキュリティ管理者役割は、管理作業を 2 つの役割に分割するのではなく、単一の結合された管理役割を作成できます。

セキュリティポリシーがデフォルトのセキュリティ管理者役割と管理者役割の能力を結合することを許す場合、新しい役割を作成して、root 役割の能力を拡張することをお勧めします。

注意 - 注意 -

サイトのセキュリティポリシーが許すならば、NIS+ クライアントから NIS+ 管理を行うことができるように root の能力を拡張することも可能ですが、お勧めできません。これを行うには、nisgrpadm(1) コマンドを使って、root が使うすべての NIS+ クライアントの名前を NIS+ グループ admin に追加します。「スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには」を参照してください。

注 -

単一の結合された管理役割を作成する場合、この役割には、両方の役割のプロファイル内に指定されているすべての承認とともに、「自分を変更することを許可」承認を与えるようにしてください。また、デフォルトの oper 役割に割り当てられているプロファイル内に指定されている承認を与えることも可能です。

管理役割によるリモートログインの許可

Trusted Solaris と Solaris の両方において、ある条件下では任意のアカウントがリモートログインでき、別の条件下では「リモートログイン」承認を持つアカウントだけがリモートログインできる場合もあります (承認が必要な条件とログインの種類については、「リモートログインの管理」を参照してください)。デフォルトの管理役割は「リモートログイン」承認を持っていますが、管理役割によるリモートログインには追加の手順が必要です。セキュリティ管理者役割は、管理役割がログインできるホストごとに、その /etc/default/login ファイルの設定を変更する必要があります。「任意の役割がリモートログインできるように設定するには」を参照してください。

新しい役割の作成

管理者役割とセキュリティ管理者役割は、 一緒に実行して新しい役割のアカウントを設定します。また、 セキュリティ管理者役割は管理者役割とともに新しいアカウントを 構成する前に、新しい役割のプロファイルを作成する必要があります。作成方法については、後述の手順を参照してください。

役割のための新しいプロファイルを作成する前に、セキュリティ管理者はその役割が作業の実行に使用するコマンドがどのような特権を必要とするかを分析しなければなりません。詳細は、第 16 章「ソフトウェアの追加」および priv_desc(4) のマニュアルページを参照してください。このマニュアルページには、そのようなコマンドに必要となる必須特権および無効化特権を決定する方法が述べてあります。

必須特権

あるコマンドまたはそのオプションの実行には特権が必要となる場合、そのような特権を「必須特権」(または「操作特権」)と呼びます。必須特権は、Trusted Solaris のマニュアルページでは「なければなりません (must have)」という説明付きで示されています。たとえば、「ifconfig(1M) コマンドはネットワークインタフェースを変更するための sys_net_config privilege 特権を持っていなければなりません」という具合です。

必須特権がコマンドに強制されていない場合、あるいは、secadmin がユーザーの実行プロファイル内のコマンドに必須特権を指定していない場合、そのコマンドまたはオプションは動作しません。

無効化特権

「1 つまたは複数の DAC または MAC 検査にパスしなかった場合には、そのコマンドは失敗する」には、「無効化特権」が必要となります。必須特権と同じように、無効化特権は、それを与えることによりユーザーの権限がユーザーの信頼レベルを超過しないこと、およびそのプロファイルに指定されている作業の範囲を超えた動作を可能にしないことを確認の上、セキュリティ管理者の指示により割り当てられます。マニュアルページでは、このようなアクセス制限を無効化するのに使われる特権の名前は ERRORS セクションに記述されています。ファイルやディレクトリに関する DAC または MAC 検査を無効化するのに使われる無効化特権を次に説明します。

DAC 無効化特権

DAC 無効化特権には、file_dac_read と file_dac_write があります。ユーザーがファイルに対する DAC アクセスを持たない場合、セキュリティ管理者は、そのファイルに対するアクセスの種類 (読み取り、書き込み、またはその両方) に合わせて、どちらかの特権を対応するコマンドに割り当てます。

MAC 無効化特権

MAC 無効化特権には、file_mac_read と file_mac_write があります。ユーザーがファイルに対する MAC アクセスを持たない場合、セキュリティ管理者は、そのファイルに対するアクセスの種類 (読み取り、書き込み、またはその両方) に合わせて、どちらかの特権を対応するコマンドに割り当てます。

無効化特権を使わない方法

プロファイル機構を使うと、セキュリティ管理者役割は、プログラムが代替 UID または GID、あるいは特定のラベルを使って、無効化特権を使わずに動作できることを指定できます。たとえば、DAC 特権の必要性をなくすには、セキュリティ管理者は、コマンドが別のユーザー ID (通常は、root ID 0) または別のグループ ID を使って、そのアクセス権または ACL に基づいてファイルまたはディレクトリにアクセスできることを実行プロファイルに指定します。

また、たとえば、あるプログラムがあるラベルのファイルを書き込みまたは読み取る必要があるとき、MAC 特権の必要性をなくすには、セキュリティ管理者は、そのプログラムが指定されている実行プロファイルにそのラベルを指定します。

セキュリティポリシーの範囲内でのセキュリティ属性の使用

コマンドがその作業の実行に必要とする特権や他のセキュリティ属性を確認した後、セキュリティ管理者役割は、そのコマンドおよび役割が、サイトのセキュリティポリシーに違反することなく、特権やその他のセキュリティ属性を使用できるだけの信頼性があることを確認する必要があります。

マニュアルページを参照してプロファイルに mount コマンド用の設定を行う例

mount(1M) コマンドは、管理者役割に割り当てられている System Maintenance プロファイルに指定されています。ここでは、セキュリティ属性の指定がどのように行われるかを示す非常に簡単な例を示すことにします。Solaris および他の UNIX オペレーティングシステムでは、一般ユーザーがオプションなしの mount コマンドを実行すると、現在マウントされているファイルシステムの名前が表示されます。ただし、root になって実行するとき、mount コマンドは、管理者 (スーパーユーザー) によって、そのコマンド行や vfstab(4) に指定したファイルシステムをマウントするのに使われる場合もあります。この場合、mount コマンドはそれを呼び出したユーザーの UID が 0 であるかどうかを検査します。

Trusted Solaris では、一般ユーザーが使用する mount コマンドの動作は Solaris の場合と同じです。しかし、管理作業を行うとき、mount は root の UID だけではなく特権も検査します。

mount(1M) のマニュアルページには、ファイルシステムをマウントするときに使われるコマンドには sys_mount 特権が必須特権であると記述されています。また、mount コマンドは、マウントポイントとマウントされるデバイスの両方に DAC と MAC の両方のアクセス権を持っている必要があります。これらのアクセス権を持っていない場合は、DAC または MAC 無効化特権が必要です (Intro(2) のマニュアルページを参照)。マウントされるファイルシステムにマウント時間セキュリティ属性が (-S オプションで) 指定されている場合、追加の無効化特権が必要になる可能性もあります。

mount (1M) のマニュアルページには、mount がファイルシステムを任意のラベルでマウントする場合、あるいは、すべてのマウント時間属性を指定する場合、セキュリティ管理者はプロファイルにおいて、次のすべての操作特権および必須特権 (file_mac_read、file_dac_read、file_mac_write、file_dac_write、 file_mac_search、file_dac_search、net_privaddr、proc_setsl、 proc_setil、sys_mount、 および sys_trans_label) を mount コマンドに割り当てる必要があると記述されています。

デフォルトの役割向けに実行プロファイルをカスタマイズ

実行プロファイルを役割ごとにカスタマイズするために 4 つのカスタム役割実行プロファイルが用意されていますが、それを次の表に示します。

表 4-3 カスタム役割プロファイル
 Custom Admin Role
 Custom Root Role
 Custom Secadmin Role
 Custom Oper Role

これらのプロファイルを使うことによって、役割プロファイルにどのような変更が行われたかが常に記録されます。各役割の (単一の) プロファイルにまとめて変更を行うことによって、デバッグが簡単になり、サービス要求を行うときにもシステムの状態を伝えやすくなります。どのプロファイルに対して、どの役割が変更を加えるかに関して、次のような制約があります。

adminvi から vi への名前の変更

デフォルトでは、すべての役割に、vi(1) ではなく、制限付きエディタ adminvi(1M) が割り当てられています。また、デフォルトでは、dtterm(1) 端末もすべての役割に割り当てられています。役割が adminvi ではなく vi と間違って入力した場合、次のエラーメッセージが表示されます。 


vi: command not in profile

/etc/security/tsol/home/role_name ディレクトリにあるすべての役割用のデフォルトの profile(4) ファイルには、次のような adminvi を vi に変更する別名機能があります。

vi() { adminvi $1 ; }

この別名は、役割が使う各ホストの $HOME/.Xdefaults-hostname ファイルに次のようなエントリを入力するまで機能しません。役割が作業する SLD ごとに、このファイルのコピーが存在する必要があります。 


Dtterm*LoginShell: true

どのスタートアップファイルが読み込まれるかの詳細は、第 3 章「ユーザーアカウントの管理」 「Trusted Solaris システムにおけるスタートアップファイルの管理」 を参照してください。.Xdefaults-hostname にそれをサポートするエントリを入力するための手順については、「dtterm により新規シェルをログインシェルとして起動させるには」を参照してください。

役割のデフォルトエディタとしての trusted_edit の割り当て

/usr/dt/bin/trusted_edit スクリプトは、$EDITOR 環境変数を使用した編集ウィンドウを起動するラッパー (wrapper) です。これは、すべての変更内容を監査します。trusted_edit を役割用のエディタとして使用するには、セキュリティ管理者は、trusted_edit スクリプトをアカウントの有効な実行プロファイルに追加し、proc_audit_tcb 特権をスクリプトに割り当てます。

必要に応じて、セキュリティ管理者あるいはそれの影響を受ける役割担当者は、trusted_edit を vi として使用することができます。その手順については、「trusted_edit エディタを役割に割り当てるには」を参照してください。

役割を管理する手順

スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには

  1. NIS+ マスターにログインし、セキュリティ管理者役割になります。

  2. NIS+ マスターにログインし、nisgrpadm(1) コマンドを使って、NIS+ グループ admin にエントリを追加します。

    1. スーパーユーザーが NIS+ クライアントから NIS+ を管理できるように設定するには、nsgrpadmin -a、管理グループ名、およびスーパーユーザー役割が NIS+ をリモート管理したいすべての NIS+ クライアントの完全修飾名を (この順番で) 入力します。


      $ nisgrpadm -a admin fully_qualified_hostname .  .  .

      たとえば、次の行は、sun.com の security ドメインに 2 つのホスト (trusted と trustworthy) を追加します。


      $ nisgrpadm -a admin trusted.security.sun.com. trustworthy.security.sun.com.

    2. 新しい役割が NIS+ クライアントから NIS+ を管理できるように設定するには、nsgrpadmin -a、管理グループ名、および新しい役割の完全修飾名を (この順番で) 入力します。


      $ nisgrpadm -a admin role's_principal_name .  .  .

      たとえば、次の行は、sun.com の security ドメインに新しい役割を追加します。


      $ nisgrpadm -a admin newrole.security.sun.com.

任意の役割がリモートログインできるように設定するには

注 -

他のリモートログインの前提条件については、「リモートログインの管理」と 「管理役割によるリモートログインの許可」を参照してください。

次の手順は、役割がリモートログインするホストごとに行います。

  1. ログインし、セキュリティ管理者役割になります。

    必要であれば、「ログイン後、特定の管理役割になるには」を参照してください。

  2. 「管理用エディタ (Admin Editor)」アクションを使って、/etc/default/login ファイルを開いて編集します。

  3. CONSOLE 行をコメントアウトします。


    #CONSOLE=/dev/console

新しい役割を設定するには

  1. 新しい役割の責任を定義します。また、その役割が作業を行うのに必要とするコマンド、アクション、承認を定義します。

  2. コマンドがその作業に特権や他のセキュリティ属性を必要とするかどうか、役割とコマンドがそのセキュリティ属性を信頼できる方法で使用できるかどうかを決定します。

  3. 役割が新しい実行プロファイルを必要とするかどうかを決定します。必要とする場合はそれを作成します。

    「プロファイルマネージャ (Profile Manager)」を使って新しいプロファイルを作成する方法については、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。既存のプロファイルとそのコマンド、アクション、承認の一覧については、付録 A 「プロファイル概要テーブル」を参照してください。

  4. 新しい役割のためのアカウントを作成します。

    役割アカウントを作成するための前提知識と手順については、第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

  5. NIS+ グループ admin に新しい役割用のエントリを作成します。

    必要であれば、「スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには」を参照してください。

trusted_edit エディタを役割に割り当てるには

trusted_edit コマンドが役割の実行プロファイルに含まれていないときは、次のことを行なってください。

  1. ログインし、セキュリティ管理者役割になります。

    必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

  2. trusted_edit コマンドをアカウントの実行プロファイルの 1 つに追加します。

    必要に応じて、「管理役割をカスタマイズするには」を参照してください。

  3. /usr/dt/bin/trusted_edit スクリプトを追加します。

  4. スクリプトに proc_audit_tcb 特権を与えます。

    注 -

    残りの手順は、プロファイル内で「管理用エディタ (Admin Editor)」アクションが割り当てられている secadmin などの役割だけが実行できます。

  5. 下記の手順で、別名で trusted_edit を vi コマンドに変更します。

    1. /etc/security/tsol/home/role_name のホームディレクトリ内で .profile ファイル内の vi 機能を検索します。


      vi() {adminvi $1;}

    2. adminvi を trusted_edit と置き換えます。


      vi() {trusted_edit $1;}

    3. 次のエントリがユーザーが作業する各 SLD の $HOME/.Xdefaults-hostname ファイルにもあることを確認します。


      Dtterm*LoginShell: true
      注 -

      このファイルは、役割が使うホストごとに作成します。たとえば、役割が trusted と trustworthy というホストで作業する場合、SLD ごとに、$HOME/.Xdefaults-trusted と $HOME/.Xdefaults-trustworthy のファイルを作成します。

    注意 - 注意 -

    trusted_edit はウィンドウを起動するため、コマンド行編集用には使うことができません。リモートログインセッションでは、コマンド行編集が唯一の選択肢である可能性もあります。したがって、役割がリモートでコマンド行編集を行わないことが判明している場合以外には、役割が利用できるエディタとして trusted_edit だけを割り当てることは避けてください。