Security for the Rational Build Agent

Security information that you must consider when you configure the Rational® Build Agent to run commands or builds on z/OS®.

Authority of the build agent

The authority of the Rational Build Agent to run commands or builds on z/OS is determined by: Start of change
  • The user ID on the build agent definition
  • Start of changeBuild Agent Authentication Overrides that might be specified if magic_login is specifiedEnd of change
End of change
Beginning with RTC 6.0.3, running the build agent as a super user is no longer required to use RACF for authentication and to use Build Agent Authentication Overrides.
If magic_login is not specified in bfagent.conf
  • The build agent definition can use a super user or a non-super user ID.
  • The build runs under the authority of the user that is specified on the Build Agent tab of the build engine definition. However, you can use Build Agent Authentication Overrides to allow users to submit builds under their own authority when they request a build.
If magic_login is specified and a non-super user starts the build agent
  • You need to configure the magic_login parameter in bfagent.conf to ensure that the build user is authenticated when it connects to the build agent.
  • The user that is specified on the Build Agent tab of the build engine definition must match the user that is specified in the magic_login paremeter.
  • The build runs under the authority of the user that started the build agent, even if the user is not the same user that is listed in the magic_login parameter or on the Build Agent tab of the build engine definition.
  • You cannot use Build Agent Authentication Overrides to make the build run under the authority of a different user when you request a build.

    This configuration could be used to limit builds to running only under the owner of the build agent process on z/OS.

Security requirements for running JCL builds

Start of changeIf the build agent you are configuring is also used for JCL builds and you want users to submit JCL builds under their own authority, you must specify the enable_credential_retention parameter in bfagent.conf and start the build agent without magic_login. For more information, see Prerequisites and security considerations.End of change

Security requirements for UNIX Systems Services directories used by the build agent

There are two access requirements for user IDs associated with the build agent:
Write access is required for build agent temporary directory

Start of changeThe user ID under which the build agent is running requires write access to the build agent temporary directory. By default, this directory is /tmp. You can specify the build agent temporary directory by using the tmpdir keyword in bfagent.conf. This directory must already exist.End of change

Start of changeAll users who submit build requests from their user accounts must have permission to write to the build agent temporary directory.End of change

Start of changeIf you run the agent with the magic_login parameter or a certificate, in which case the agent does not change user identities, you can give the temporary directory more strict permissions. End of change

Execution permission is required for user ID home directory
The home directory of the user ID that starts the build agent must allow execution permission to the user ID listed in the build agent definition or access must be provided when the build is submitted or the build fails with a message like:
EXEC unable to set working directory to /u/userX (111).
Where userX is the user ID that started the build agent.
Use one of the following strategies to grant execution permission to the HOME directory:
  • On the HOME directory for the user ID that starts the build agent, grant execution permission for the user name that is listed for Build Agent Authentication on the Build Agent tab of the build engine.
  • Modify the build agent shell script to define a HOME variable that points to a different directory. Configuring a HOME variable in the build agent script is typically required when the user does not have an environment variable set, but in this case, the HOME variable is being used as a workaround to avoid granting execution permission to the build user’s actual HOME directory. For example, export HOME=/u/dummybuilder changes the build agent init directory to /u/dummybuilder.

video icon Video channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community forums library

support icon Support

IBM Support Community
Deployment wiki