どのアプリケーションが SIOCSVIPA ioctl 呼び出しの発行または MODDVIPA ユーティリティーの呼び出しを行って DVIPA を作成できるかを制御するステップ

VIPARANGE ステートメントで動的 VIPA (DVIPA) へのアクセスを制御するために、System Authorization Facility (SAF) リソース・プロファイルを SERVAUTH クラスに定義できます。

手順

アプリケーションが SIOCSVIPA ioctl 呼び出しの発行または MODDVIPA ユーティリティーの呼び出しを行って DVIPA を作成できるかどうかを制御するには、以下のステップを実行します。

  1. 以下の RACF® コマンドを発行して、EZB.MODDVIPA.sysname.tcpname リソース・プロファイルを SERVAUTH クラス内に定義します。 
    RDEFINE SERVAUTH (EZB.MODDVIPA.sysname.tcpname) UACC(NONE)
  2. 以下の RACF コマンドを発行して、アプリケーションに関連付けられているユーザー ID にリソースへの READ アクセスを与えます。 
    PERMIT EZB.MODDVIPA.sysname.tcpname  ACCESS(READ) CLASS(SERVAUTH) ID(userid)
  3. 以下の RACF コマンドを発行して、プロファイルをリフレッシュします。 
    SETROPTS RACLIST(SERVAUTH) REFRESH

タスクの結果

この例では sysname は MVS™ システムの名前、tcpname は TCP/IP 開始タスクのジョブ名、そして userid は、アプリケーションに関連付けられているユーザー ID です。 TCP/IP のような開始済みタスクのジョブ名は、 その開始の仕方によって変わってきます。

結果:
  • このリソース・プロファイルは定義済みであり、そのユーザー ID がそのリソースに対する READ アクセスを持つ場合、その呼び出しは処理されます。
  • このリソース・プロファイルが定義済みでなく、ユーザー ID が APF 許可もなく UNIX System Services スーパーユーザーでもない場合、その呼び出しは失敗します。
  • このリソース・プロファイルが定義済みであって、ユーザー ID がそのリソースに READ アクセスできない場合、そのユーザーがスーパーユーザーであるかどうかに関係なく、その呼び出しは許可拒否エラーとともに失敗します。
規則:
  • 特定およびワイルドカードのリソース・プロファイルの名前が定義済みの場合、ユーザー ID は、最も厳密に一致するリソースに対する READ アクセスが必要です。 例えば、EZB.MODDVIPA.MVS1.TCPCS1 および EZB.MODDVIPA.MVS1.* と定義すると、結果は次のようになります。
    • システム MVS1、TCP/IP スタック TCPCS1 上で DVIPA を作成するには、ユーザー ID は、EZB.MODDVIPA.MVS1.TCPCS1 に対する READ アクセスが必要です。
    • システム MVS1、TCP/IP スタック TCPCS2 上で DVIPA を作成するには、ユーザー ID は、EZB.MODDVIPA.MVS1.* に対する READ アクセスが必要です。
    • ユーザー ID がシステム MVS2 で TCP/IP スタック上に DVIPA を作成しようとしても、一致するリソース・プロファイルはありません。
  • このリソース・プロファイルが定義済みの場合、ユーザー ID は、SIOCSVIPA ioctl 呼び出し、SIOCSVIPA6 ioctl 呼び出し、または MODDVIPA ユーティリティーを使用して作成された DVIPA を削除するには、そのリソースに対する READ アクセスも必要です。
親トピック: SIOCSVIPA、 SIOCSVIPA6、 MODDVIPA のためのセキュリティー・プロファイルの定義