Group-based security for z/OS UNIX System Services directories

By default, the z/OS UNIX directories created by the configuration software for self describing agent (SDA) application support files are created with group and user directory permissions MODE(7,5,5), which sets permission as read-write-execute (7) for the owner, and read-execute (5) for all others (group and others). If you would like to implement a more secure access scheme for the directories, you can do so with group-based security.

The TEMS_MANIFEST_PATH parameter in the KDSENV member points to the name of the z/OS UNIX home directory where uploaded agent jar files and other application support files will be stored by the monitoring server. The parameter value consists of the runtime environment directory name followed by &rtename/kds/support/TEMS. By default, the KCIJPUSS job (PARMGEN) creates the RKANDATV(KDS*) z/OS UNIX members to invoke the mkdir commands for the TEMS_MANIFEST_PATH directory and subdirectories with owner, group and others in permission MODE(7,5,5). For example, one of the mkdir commands processed by the PARMGEN KCIJPUSS job in WKANSAMU is this mkdir member in RKANDATV library: 

 VIEW   &rte_hilev.&rte_name.RKANDATV(KDSRMKDB) 
%mkdir '/rtehome/ibmuser1/USSRTE1/kds/support/TEMS' MODE(7,5,5) +
The last 5 permission bit in the MODE(7,5,5) parameter grants read-execute permission to the z/OS UNIX directories for the runtime environment to all users. Note that the TSO user ID of the person running the job is not necessarily the user ID associated with the monitoring server started task. However, both user IDs require write access to the z/OS UNIX directories for the following reasons:
  • To support the self describing agent feature, the z/OS® monitoring server must be able to add and remove files from these directories. A more restrictive MODE() parameter would prevent the monitoring server from doing so.
  • The TSO user ID of the person running the z/OS UNIX jobs must have write access to these same directories.
To implement a more secure access scheme for the z/OS UNIX directories, use group-based security, as illustrated by the following example:
Assume that the TSO user ID ibmuser1 is connected to three security groups, GROUP1, GROUP2, and GROUP3. Since GROUP1 is ibmuser1's default group, all of the newly created z/OS UNIX directories are owned by GROUP1 by default. The user ID of the monitoring started task is CANSDSST and it is connected to two security groups, GROUP2 and GROUP4. Since both user IDs have GROUP2 in common, the ibmuser1 user ID could log on to z/OS UNIX and issue a chgrp command to set GROUP2 as the owner of the runtime environment's z/OS UNIX directories. For example: 
/rtehome/ibmuser1> chgrp -R GROUP2 USSRTE1
Next, the ibmuser1 user ID can issue a chmod command to change the original MODE(7,5,5) value, such as: 
/rtehome/ibmuser1> chmod -R 775 USSRTE1
After this chmod command is issued, only users who are connected to GROUP2 will have write access to the z/OS UNIX directories for the runtime environment.

If the TSO user ID and monitoring server started task user IDs do not have any security groups in common, you would need to either connect one or both of the user IDs to a common security group, or define a new security group and connect both user IDs to that group. With either option, you still need to perform the chgrp and chmod actions.