Introduction

The JS7 Agent for Unix

...

runs 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 involves logging in as that user, optionally to load loading the user profile and to execute executing 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 the use of sudo to switch to other user accounts.
  • This requires configuration of 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 of ownership.
  • This allows the Agent to switch to any user account using su.
  • Operating the Agent as root is not recommended as this includes unlimited permissions and introduces security risks.

Using sudo from a non-root Account

A shell job script can use sudo to allow user switching of

Prerequisites

To allow user switching the Agent's run-time account has to be added to the account as follows:

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 multi-line 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 multi-line 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:
  
  

Image Added

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

Image Added

Using Script Includes in Jobs

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

Image Added

The Script Editor provides the Image Added folder icon to open the list of available Script Includes like this:

Image Added

Users can navigate to select the desired Script Include:

Image Added

As a result the job script holds calls to the pairing Script Includes for the begin and 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:

Image Added

Explanation:

• Use of <user> is an example of a placeholder being used in the Script Include.
• Any string can be considered a placeholder which 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 name is used when calling the Script Include.
  • The first argument value specifies the search string in the Script Include.
  • The second argument value 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