Complete Guide to Executing Commands as Different Users in Bash Scripts Using sudo

Problem Background and Challenges

In Linux system administration, executing commands under different user identities within scripts is a common requirement. The original problem describes a typical scenario where a script needs to switch to a specified user, navigate to a specific directory, and perform version control operations. The traditional su $USERNAME approach suffers from execution flow interruption, as su initiates a new shell session, preventing subsequent commands from executing in the target user's environment.

Core Solution with sudo Command

Using sudo -u username command represents the optimal solution to this challenge. Unlike su, sudo can execute commands under a specified user identity without starting an interactive shell, maintaining the continuity of script execution flow.

Basic Implementation: Single Command Execution

The most fundamental approach involves passing target commands as parameters to sudo:

sudo -u username2 -H sh -c "cd /home/$USERNAME/$PROJECT; svn update"

Here, the -H parameter ensures the use of the target user's home directory environment, while sh -c enables execution of multiple command sequences. Environment variables $USERNAME and $PROJECT must be properly set before executing sudo.

Permission Configuration: sudoers File Setup

To enable passwordless execution, appropriate configuration must be added to the /etc/sudoers file:

username1 ALL=(username2) NOPASSWD: /path/to/svn

This configuration permits username1 to execute the specified svn command as username2 without requiring a password. For multi-user scenarios, group permissions can be utilized:

%developers ALL=(deploy) NOPASSWD: /usr/bin/svn

Advanced Techniques: Multiple Command Execution and Script Encapsulation

For complex command sequences, heredoc syntax or external script encapsulation can be employed:

sudo -i -u someuser bash << EOF
echo "Initiating user operations"
cd /home/someuser/project
svn update
make build
EOF

This approach is suitable for executing related operations while maintaining logical integrity. An alternative method involves encapsulating target operations as standalone scripts:

#!/bin/bash
# deploy_script.sh
cd /home/$1/$2
svn update
# Additional deployment operations

# Invocation from main script
sudo -u deployuser /path/to/deploy_script.sh $USERNAME $PROJECT

Script Restart Technique

For scenarios requiring complete user identity switching for all subsequent operations, exec combined with script restart provides an effective solution:

#!/bin/bash
if [ $UID -eq 0 ]; then
  user=$1
  dir=$2
  shift 2
  cd "$dir"
  exec su "$user" "$0" -- "$@"
fi

echo "Current user ID: $UID"
# Subsequent code executed under target user identity

This technique replaces the current process via exec, ensuring all subsequent code executes entirely within the target user's environment.

Alternative Approach: systemd Service Integration

For complex production environment deployments, systemd services offer a viable alternative. Create a oneshot service:

[Unit]
Description=Project Deployment Service
[Service]
Type=oneshot
User=deployuser
ExecStart=/usr/local/bin/deploy_script.sh
[Install]
WantedBy=multi-user.target

When combined with Polkit rules for permission management, other users can trigger execution via systemctl start service-name, benefiting from systemd's logging and process monitoring capabilities.

Security Considerations and Practical Recommendations

In actual deployments, key security factors require attention: command paths must use absolute paths to prevent path hijacking, sudoers rules should follow the principle of least privilege, and sensitive operations require audit logging. Production environments should integrate configuration management tools for centralized permission management and version control.

Performance and Maintainability Analysis

The sudo approach demonstrates superior performance compared to su by avoiding unnecessary shell startup overhead. While the script restart technique offers powerful functionality, it increases code complexity and suits specific scenarios. The systemd approach provides optimal maintainability and monitoring capabilities, though with relatively complex configuration. Appropriate implementation methods should be selected based on specific requirements.