ログイン イベントの認識

では、プロセスのユーザ ID を変更しようとするすべての試みがログイン イベントとして認識されるわけではありません。通常、プログラムでは、setuid システム コールを使用してユーザ ID を変更します。SURROGATE クラスがこれらのイベントを制御します。これらのイベントは、必ずしもログイン イベントとはみなされません。これらのイベントは から見ると、必ずしもユーザ ID を変更しません。
capamsc141
Privileged Access Manager
では、プロセスのユーザ ID を変更しようとするすべての試みがログイン イベントとして認識されるわけではありません。通常、プログラムでは、setuid システム コールを使用してユーザ ID を変更します。SURROGATE クラスがこれらのイベントを制御します。これらのイベントは、必ずしもログイン イベントとはみなされません。これらのイベントは
Privileged Access Manager
から見ると、必ずしもユーザ ID を変更しません。
Privileged Access Manager
では、ユーザが最初のログイン時に使用した、元のユーザ ID が常に保持されます。通常の setuid システム コールを実行しても、
Privileged Access Manager
ではユーザ ID の変更は登録されません。
Privileged Access Manager
が ID の変更を認識するには、このイベントをログイン イベントとして認識する必要があります。この製品では、ログイン イベントは、以下のルールを使用して認識されます。
  • ID の変更を試みるプログラムは、ログイン プログラムとして定義されます。
    LOGINAPPL クラスのすべてのプログラムがログイン プログラムです。
  • このプログラムは、LOGINAPPL クラスの定義に対応する一連のシステム コールを実行します。
管理セッションを(selang または
Privileged Access Manager
 エンドポイント管理で)開始すると、
Privileged Access Manager
によってダミー ログイン イベントが実行されます。このイベントは実際のログインではなく、
Privileged Access Manager
のログイン チェックと同様の一定の内部チェックが実行されます。
詳細については、「
selang リファレンス ガイド
」で LOGINAPPL クラスの SEQUENCE プロパティの説明を参照してください。
管理セッションの開始時には、管理対象のマシンでユーザ名がチェックされます。管理対象マシンにアクセスするには、セッションを実行する端末の WRITE アクセス権が必要です。
たとえば、ホスト Minerva にログインした状態でホスト Artemis の
Privileged Access Manager
を管理するには、以下の 2 つの条件が満たされている必要があります。
  • Minerva という名前(または適切な完全修飾名)の TERMINAL オブジェクトが Artemis のデータベース レコード内にあること
  • 管理者がこのオブジェクトの ACL に WRITE アクセス権付きで登録されていること
これらの条件は、他のユーザ権限チェックよりも前にチェックされます。データベースでは、管理者権限も必要です。