You can define a System Authorization Facility (SAF) resource
profile in the SERVAUTH class to control access to dynamic VIPAs (DVIPAs)
in a VIPARANGE statement.
Procedure
Perform the following steps to control whether an application
can issue a SIOCSVIPA ioctl call or call the MODDVIPA utility to create
a DVIPA:
- Define the EZB.MODDVIPA.sysname.tcpname resource
profile in the SERVAUTH class by issuing the following RACF® command:
RDEFINE SERVAUTH (EZB.MODDVIPA.sysname.tcpname) UACC(NONE)
- Give the user ID that is associated with the application
READ access to the resource by issuing the following RACF command:
PERMIT EZB.MODDVIPA.sysname.tcpname ACCESS(READ) CLASS(SERVAUTH) ID(userid)
- Refresh the profile by issuing the following RACF command:
SETROPTS RACLIST(SERVAUTH) REFRESH
Results
In this example, sysname is
the name of the MVS™ system, tcpname is
the job name of the TCP/IP started task, and userid is
the user ID that is associated with the application. The job name
for started tasks, such as TCP/IP, is derived depending on how it
is started:
- If the START command is issued with the name of a member in a
cataloged procedure library (for example, S TCPIPX), the job name
will be the member name (for example, TCPIPX).
- If the member name on the START command is qualified by a started
task identifier (for example, S TCPIPX.ABC), the job name will be
the started task identifier (for example, ABC). The started task identifier
is not visible to all MVS components,
but TCP/IP uses it to build the RACF resource
name.
- The JOBNAME parameter can also be used on the START command to
identify the job name (for example, S TCPIPX,JOBNAME=XYZ).
- The JOBNAME can also be included on the JOB card.
Results: - If this resource profile is defined and the user ID has READ access
to the resource, then the call is processed.
- If this resource profile is not defined and the user ID is not
APF authorized and is not a UNIX System
Services superuser, the call fails.
- If this resource profile is defined and the user ID does not have
READ access to the resource, then the call fails with a permission
denied error, regardless of whether the user is a superuser.
Rules: - If specific and wildcard resource profile names are defined, the
user ID must have READ access to the resource that has the most specific
match. For example, defining EZB.MODDVIPA.MVS1.TCPCS1 and EZB.MODDVIPA.MVS1.*
has the following results:
- To create a DVIPA on system MVS1, TCP/IP stack TCPCS1, the user
ID must have READ access to EZB.MODDVIPA.MVS1.TCPCS1.
- To create a DVIPA on system MVS1, TCP/IP stack TCPCS2, the user
ID must have READ access to EZB.MODDVIPA.MVS1.*.
- If a user ID tries to create a DVIPA on a TCP/IP stack on system
MVS2, there is no matching resource profile.
- If this resource profile is defined, the user ID must also have
READ access to the resource to delete a DVIPA that was created using
the SIOCSVIPA ioctl call, the SIOCSVIPA6 ioctl call, or the MODDVIPA
utility.