Introduction

The JS7 Agent for Unix is running in a specific user account and by default will execute jobs within the context and permissions of this account.

• Running a job as a different user includes to login as that user, optionally to load the user profile and to execute commands in this context.
• User switching applies to Shell Jobs and is performed by the built-in sudo and su capabilities of the operating system.

This article applies to the JS7 Agent for Unix only. For Windows environments see JS7 - Running Jobs as a different User on Windows

Basics

Users can choose

• to operate the Agent as a non-root run-time account:
  • This allows to use sudo to switch to other user accounts.
  • This requires to configure sudo permissions for switching user accounts.
• to operate the Agent as the root run-time account:
  • This allows the Agent to execute any commands and scripts independently from ownership.
  • This allows the Agent to switch to any user account using su.
  • It is not recommended to operate the Agent as root as this includes unlimited permissions and introduces security risks.

Using sudo from a non-root Account

To allow user switching the Agent's run-time account a Shell job script can use sudo like this:

sudo -su user1 <<EOF
whoami
pwd
EOF

Explanation:

• user1 is any user account available from the operating system for which a login is performed.
• For execution of multiline commands a Here String is used:
  • The commands between <<EOF (line 1) and EOF (line 4) are executed using sudo.
  • Instead of EOF any unique string can be used that does not match one of the commands to be executed.
  • Using <<'EOF' will prevent substitution in a Here String.
• Executing sudo from a non-root account requires the sudo configuration to be in place. The location of the sudo configuration file depends on the operating system, for example /etc/sudo.conf or /etc/sudoers.
  • Example

    • To allow the Agent run-time account to run jobs on user accounts user1, user2 the following setting can be used in the sudo configuration file.

      • <run-time-account> ALL=(user1, user2) NOPASSWD: ALL

    • To allow the Agent run-time account to run jobs on all user accounts the following setting can be used:

      • <run-time-account> ALL=(ALL) NOPASSWD: ALL

    • The NOPASSWD setting is required to allow the account to use sudo without specifying a password.

Using su from the root Account

If the Agent is operated from the root account it can use the following command in a Shell job script to switch to a different user account:

su -l user1 <<EOF
whoami
pwd
EOF

Explanation:

• user1 is any user account available from the operating system for which a login is performed.
• For execution of multiline commands a Here String is used:
  • The commands between <<EOF (line 1) and EOF (line 4) are executed using su.
  • Instead of EOF any unique string can be used that does not match one of the commands to be executed.
  • Using <<'EOF' will prevent substitution in a Here String.
• Executing su from the root account does not require to specify the account's password.

Using Script Includes

Defining Script Includes 

Instead of adding the above calls to sudo or su to individual jobs the JS7 - Script Includes can be used:

• In the Configuration view a Script Include can be added from the Automation folder.
• The sudo-sos1 Script Include holds the initial line to call sudo like this:
  
  

The final line in the call to sudo is added to the sudo-end Script Include like this:

Using Script Includes in Jobs

A workflow can make use of Script Includes in any of the included jobs like this:

The Script Editor offers the folder icon to open the list of available Script Includes:

Users can navigate to select the desired Script Include:

As a result the job script holds calls to the pairing Script Includes for the begin and the end of the call to sudo like this:

#!/bin/bash

##!include sudo-sos1
pwd
whoami
##!include sudo-end 

##!include sudo-sos2
pwd
whoami
##!include sudo-end 

Explanation:

• The syntax ##!include is used to call a Script Include by its name.
• Any number of calls to Script Includes can be used in a job to allow parts of job scripts to be executed with different accounts.

Using generic Script Includes

Defining Script Includes 

Instead of hard-wiring the target account in a Script Include for sudo or su a generic approach can be used:

Explanation:

• Use of <user> is an example for a placeholder used in the Script Include.
• Any string can be considered a placeholder that can be replaced when calling the Script Include.

Using Script Includes in Jobs

A workflow can parameterize use of Script Includes in any of the included jobs like this:

• The --replace argument is used when calling the Script Include.
  • The first argument specifies the search string in the Script Include.
  • The second argument specifies the replacement string in the Script Include.
    
    

#!/bin/bash

##!include sudo-begin --replace="<user>","sos1"
pwd
whoami
##!include sudo-end 

##!include sudo-begin --replace="<user>","sos2"
pwd
whoami
##!include sudo-end