Secure execution of tasks in the administrative task scheduler

The execution threads of the administrative task scheduler always switch to the security context of the execution user before executing a task. The user is authenticated through the use of PassTickets.

The first action that is taken by the administrative task scheduler when starting task execution is to switch its security context to the context of the execution user. The execution user can be explicitly identified by the user-ID parameter of the ADMIN_TASK_ADD stored procedure, or can be the default user.

If the task is a stored procedure, and the stored procedure must be executed in DB2® with the privileges and rights of the secondary authentication IDs of the execution user, make sure that DB2 was started with a sign-on exit routine.

If the task must run under a certain authority, including an authority that is different from the caller of the stored procedure, credentials are passed on to the administrative task scheduler. These credentials are not stored anywhere. They are validated by RACF® to ensure that the caller of the stored procedure at the task definition time has the right to assume the security context. Therefore, you can use a PassTicket (encrypted single-use password) in the password parameter of the ADMIN_TASK_ADD stored procedure. If no credentials are provided, then the administrative task scheduler executes the tasks under its default execution user.

The administrative task scheduler generates and uses PassTickets for executing the tasks under the corresponding authority. Each task executes after switching to the requested security context using the user ID and the generated PassTicket.

No password is stored in the administrative task scheduler, but the administrative task scheduler is defined as a trusted program in RACF, and is allowed to get PassTickets for any user. The administrative task scheduler sub-thread requires a PassTicket from RACF and logs in using this single-use password. The execution of the task then occurs in the switched security concept, allowing the task to have access to the resources defined for this execution user. After the execution, the security context is switched back to the scheduled task user.

The started task module (DSNADMT0) of the administrative task scheduler uses the pthread_security_np() function to switch users. To set a thread-level security environment for the scheduler, follow the steps in Additional steps for enabling the administrative task scheduler and administrative enablement routines.

The administrative task scheduler resources should be protected from unintended impact when executing a task. Therefore, the started task user (STARTUID), which has access to the administrative task scheduler resources, must not be used as the default execution user (DFLTUID). Also, it should not be specified in the user-ID parameter of the ADMIN_TASK_ADD stored procedure. The administrative task scheduler will not start if the started task user and the default execution user are identical. The default execution user should have as few rights as possible to avoid impacting any resources if no user is defined for a task.

The default execution user has no authority, except to attach to DB2 and write to the JES reader.