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
andsu
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.
- This allows to use
- 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) andEOF
(line 4) are executed usingsudo
. - 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.
- The commands between
- Executing
sudo
from a non-root account requires thesudo
configuration to be in place. The location of thesudo
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 thesudo
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 usesudo
without specifying a password.
- Example
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) andEOF
(line 4) are executed usingsu
. - 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.
- The commands between
- 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 callsudo
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
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 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