...

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.
• 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.
  operate the Agent as

Using sudo from a non-root

...

• This allows to use sudo to switch to other user accounts.
• This requires to configure sudo permissions for switching user accounts.

Account

To allow user switching the Agent's run-time account can use sudo like this

Using su from the root Account

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

susudo -lsu <user> <<EOF
whoami
pwd
EOF

...

• <user> 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 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 of environment variables in a Here String.
• Executing su sudo from the a non-root account does not require to specify the account's password.

Using 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 to switch to a different user accountTo allow user switching the Agent's run-time account can use sudo like this:

sudosu -sul <user> <<EOF
whoami
pwd
EOF

...

• <user> 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 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 of environment variables in a Here String.
• Executing sudo su from a non-the root account requires does not require to specify the sudo configuration. 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

Using Script Includes

...

• 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 offers the Image Added folder icon to open the list of available Script Includes:

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

Image Added

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